Skip to content

Surpress, mark, or order superflous trait resolution type errors correctly #19406

Open
@Kimundi

Description

@Kimundi

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:

  1. Only emit all type errors that are not depended on other type errors (suppressing the superfluous errors)
  2. Emit all errors, but in the order of their dependencies so that the actual relevant errors are always the first ones.
  3. Emit all errors, but mark all that have any dependencies with a note like "This might be a spurious error"

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsC-enhancementCategory: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions