Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005903OCamltypingpublic2013-01-23 19:032017-03-07 13:47
Assigned To 
PlatformOSOS Version
Product Version 
Target VersionundecidedFixed in Version 
Summary0005903: integrate unused-variable (and other unused-*) warnings with ordinary type-error messages
DescriptionI 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.

TagsNo tags attached.
Attached Files

- Relationships
parent of 0006580closedgarrigue Confusing errors / lack of errors with labelled arguments 

-  Notes
frisch (developer)
2013-01-24 07:20

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)
2013-01-24 11:27

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.
frisch (developer)
2013-01-24 11:35

> 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.
sweeks (reporter)
2015-01-19 17:21

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.
frisch (developer)
2015-01-19 17:30

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.
sweeks (reporter)
2015-01-19 17:36

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.
shinwell (developer)
2017-03-07 13:47

I'd like to add support for improving this area. Unused variable / parameter errors are often very useful for finding errors in code that otherwise cause obscure type error messages. I hit one of these just yesterday. I wanted to remove the first parameter of a toplevel function, which I did everywhere, except actually in the "let foo = ..." line by accident. This caused an obscure error message in the next toplevel function, when in fact, it should have just said "unused parameter ..." when it had finished type checking "foo". This probably wasted ten or fifteen minutes.

- Issue History
Date Modified Username Field Change
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 / +beta1
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
2016-04-14 17:23 doligez Target Version 4.03.0+dev / +beta1 => 4.03.1+dev
2017-02-16 14:01 doligez Target Version 4.03.1+dev => undecided
2017-02-23 16:45 doligez Category OCaml typing => typing
2017-03-07 13:47 shinwell Note Added: 0017589
2017-03-07 13:47 shinwell Severity tweak => feature

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker