-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Surpress, mark, or order superflous trait resolution type errors correctly #19406
Comments
I'm not able to reproduce the error messages described above. In fact, the following code currently compiles on nightly: fn main() {
let _x = "1 2 3".split(" ").collect::<Vec<_>>();
} |
Yes let v: Vec<_> = "1, 2, 3".split(b',').collect(); <anon>:2:43: 2:52 error: no method named `collect` found for type `core::str::Split<'_, u8>` in the current scope
<anon>:2 let v: Vec<_> = "1, 2, 3".split(b',').collect();
^~~~~~~~~
<anon>:2:43: 2:52 note: the method `collect` exists but the following trait bounds were not satisfied: `u8 : core::str::pattern::Pattern<'static>`, `core::str::Split<'_, u8> : core::iter::Iterator`
<anon>:2:31: 2:42 error: the trait `core::ops::FnMut<(char,)>` is not implemented for the type `u8` [E0277]
<anon>:2 let v: Vec<_> = "1, 2, 3".split(b',').collect();
^~~~~~~~~~~
<anon>:2:31: 2:42 error: the trait `core::ops::FnOnce<(char,)>` is not implemented for the type `u8` [E0277]
<anon>:2 let v: Vec<_> = "1, 2, 3".split(b',').collect(); The new version seems a bit better, with the note! |
I don't understand why the closure traits are “privileged” in that they are explicitly mentioned. |
I'm not sure if this means that the kinds of error messages that this issue are talking about are gone now, but that new NOTE definitely improves matters for this specific kind of type error. |
Triage: @bluss's example with the new format
can this be closed? |
I think we can close, but I'm having a hard time understanding exactly what @Kimundi was trying to highlight in their example. |
I believe the idea originally proposed is that only the first trait error should be emitted. In some way, the entire statement should be "poisoned" after encountering a trait bound error so that no other error is generated in that line, much like #46732 does for blocks that encounter a parse error. For the record, the current output is shorter still:
|
I believe the ideal output would avoid emitting the E0599 which is a knock down effect of the E0277 error. That being said, I believe all we could do is always hide it (even if it would fail regardless). As things stand, I don't think we'll improve this diagnostic any time soon. |
Current output:
|
Current output:
|
Current output:
|
Current output:
|
During a
rusti
session on IRC, a confusing class of type errors has been discovered. This piece of code:Currently emits these two error messages:
Where
&str
does not implementCharEq
andsplit()
is defined asfn split<Sep: CharEq>(&self, s: Sep) -> CharSplit<, Sep>
Both are correct type errors, however the second error is confusing because its not he actual cause, AND it depends on the other type error existing, which IS the actual cause.
Furthermore, sometimes those two errors are emitted in a different order, making it even more confusing to understand.
The basic reasoning here is "&str does not implement CharEq" and "CharSplits<'_, &str> does not Implement something that provides collect() because the only candidate, Iterator, is only implemented if &str implements CharEq". However, the
split
invocation only typechecks if&str
implementsCharEq
, and hence any type error on the return type becomes irrelevant, as the type would not be valid to begin with.If possible, typecheck should construct a dependency graph between the type errors it encounters, so that for every pair of type errors
a, b
it is known ifb
depends ona
.Using this information, the error messages could be improved in a few ways:
The text was updated successfully, but these errors were encountered: