|Anonymous | Login | Signup for a new account||2015-11-30 01:55 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005903||OCaml||OCaml typing||public||2013-01-23 19:03||2015-01-19 17:36|
|Target Version||4.03.0+dev||Fixed in Version|
|Summary||0005903: integrate unused-variable (and other unused-*) warnings with ordinary type-error messages|
|Description||I think it would be preferable if unused-variable warnings appeared in|
the same order and interspersed with ordinary type-error messages,
rather than all appearing after the ordinary type errors. They
sometimes provide information that is helpful in resolving type
errors. And, this would allow one to focus on one piece of code and
resolve errors in it at the same time and move on, rather than having
to jump back to a piece of code that you thought had passed already
the type checker.
|Tags||No tags attached.|
|Warnings on unused stuff need to wait until type-checking is done, so the only solution I can see is to keep all warnings in a buffer, and sort them by location before displaying them (and be careful to do that even in case of type error). If someone wants to propose a patch...|
Boris Yakobowski (reporter)
|I'm not convinced that this would be useful. Some warnings used to be intermingled with errors, and it was quite painful to skip through them before reaching the real error. In particular, when you're developing new code, warnings for unused things are bound to happen (partially written functions, functions not called yet, etc), and I clearly do not want to see them before a typing error.|
> I clearly do not want to see them before a typing error.
Oh, don't worry I don't think there is a plan to do that. Currently the warnings require the whole source to be type-checked (because they are no longer done syntactically on the Parsetree), but the type-checker stops at the first error. In some cases, it might be possible to detect before the end of the type-checking that some stuffs are definitely unused (and so be able to report it even in case of a type-error later), but this is quite difficult to do.
My understanding of the feature wish was that those unused-stuff warnings should appear "between" other "warnings turned into errors", not real type errors.
|I want the error reporting mechanism to not distinguish between unused-variable errors and type errors, and would like them to be reported with the same priority -- I would like all errors to be reported in the same way, sorted by line number. I don't want certain kinds of errors to be skipped. I don't care what the default behavior is, as long as there is a way to configure this behavior.|
|I don't think it is possible to achieve what you want as long as the type-checker stops on the first error. The unused-variables "errors" can only be reported when the scope of the variable is fully type-checked, so when this scope contains (another) type error, you cannot get the unused-variable error. The only way I can see to achieve what you want would be to rely on a syntactic approximation of the unused-variable criterion i.e. the old algorithm to implement those warnings. The new approach is more precise and adding back support for the old one (in addition to the new one) seems to add too much complexity for the gain.|
I can imagine there would be some trickiness to implement this for module-level variables, but for local variables, I would have thought it would be easy and that there would be a natural place where the type-checking code is finished processing the scope of a local variable, and could report at that point if the variable is unused.
Clearly not a big issue.
|2013-01-23 19:03||sweeks||New Issue|
|2013-01-24 07:20||frisch||Note Added: 0008790|
|2013-01-24 11:27||Boris Yakobowski||Note Added: 0008792|
|2013-01-24 11:35||frisch||Note Added: 0008793|
|2013-06-19 20:42||doligez||Severity||minor => tweak|
|2013-06-19 20:42||doligez||Status||new => acknowledged|
|2013-06-19 20:42||doligez||Target Version||=> 4.02.0+dev|
|2013-07-12 18:15||doligez||Target Version||4.02.0+dev => 4.01.1+dev|
|2014-05-25 20:20||doligez||Target Version||4.01.1+dev => 4.02.0+dev|
|2014-07-16 20:45||doligez||Target Version||4.02.0+dev => 4.02.1+dev|
|2014-09-04 00:25||doligez||Target Version||4.02.1+dev => undecided|
|2014-09-22 21:59||doligez||Target Version||undecided => 4.02.2+dev / +rc1|
|2014-09-26 00:42||garrigue||Relationship added||parent of 0006580|
|2015-01-16 22:18||doligez||Target Version||4.02.2+dev / +rc1 => 4.03.0+dev|
|2015-01-19 17:21||sweeks||Note Added: 0013147|
|2015-01-19 17:30||frisch||Note Added: 0013148|
|2015-01-19 17:36||sweeks||Note Added: 0013149|
|Copyright © 2000 - 2011 MantisBT Group|