Description
During a rusti
session on IRC, a confusing class of type errors has been discovered. This piece of code:
fn main() {
"1 2 3".split(" ").collect::<Vec<_>>()
}
Currently emits these two error messages:
figment_sketch.rs:2:13: 2:23 error: the trait `core::str::CharEq` is not implemented for the type `&str`
figment_sketch.rs:2 "1 2 3".split(" ").collect::<Vec<_>>()
^~~~~~~~~~
figment_sketch.rs:2:24: 2:43 error: type `core::str::CharSplits<'_, &str>` does not implement any method in scope named `collect`
figment_sketch.rs:2 "1 2 3".split(" ").collect::<Vec<_>>()
^~~~~~~~~~~~~~~~~~~
Where &str
does not implement CharEq
and split()
is defined as fn 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
implements CharEq
, 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 if b
depends on a
.
Using this information, the error messages could be improved in a few ways:
- Only emit all type errors that are not depended on other type errors (suppressing the superfluous errors)
- Emit all errors, but in the order of their dependencies so that the actual relevant errors are always the first ones.
- Emit all errors, but mark all that have any dependencies with a note like "This might be a spurious error"