suppress duplicate error messages in trait reporting #21528
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
E-mentor
Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Comments
nikomatsakis
added
A-collections
|
Marking as mentor. |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Jan 30, 2015
arielb1
pushed a commit
to arielb1/rust
that referenced
this issue
Sep 26, 2015
Because of type inference, duplicate obligations exist and cause duplicate errors. To avoid this, only display the first error for each (predicate,span). The inclusion of the span is somewhat bikesheddy, but *is* the more conservative option (it does not remove some instability, as duplicate obligations are ignored by `duplicate_set` under some inference conditions). Fixes rust-lang#28098 cc rust-lang#21528 (is it a dupe?)
brson
pushed a commit
to brson/rust
that referenced
this issue
Oct 16, 2015
Because of type inference, duplicate obligations exist and cause duplicate errors. To avoid this, only display the first error for each (predicate,span). The inclusion of the span is somewhat bikesheddy, but *is* the more conservative option (it does not remove some instability, as duplicate obligations are ignored by `duplicate_set` under some inference conditions). Fixes rust-lang#28098 cc rust-lang#21528 (is it a dupe?)
|
Closing per @fhahn . |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons).
I think the best thing is just to add some sort of hashset and check for duplicates in
librustc::middle::traits::error_reportingor maybelibrustc_typeck::check::vtable. But we should do this check after doing full type resolution.I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.
The text was updated successfully, but these errors were encountered: