Error code E0116 causes high volume of incorrect compiler errors

[anthonydandrea]

Hello! When an E0116 is present in a codebase, it causes a very large slew of other unrelated and incorrect errors to get printed to the terminal. Even though it's a beginner Rust mistake, this is extremely hard to diagnose in any codebase.

Possible solutions might be:

1. If E0116 is found, just print that, and skip printing any other errors (preferred)

2. If E0116 is found, print it at the very end (not preferable, as there may be hundreds of errors which print first)

Code

fn main() {
    let x = "hello";
    x.split(" ");
}

impl Vec<usize> {}

Meta

rustc --version --verbose:

rustc 1.78.0 (9b00956e5 2024-04-29) (built from a source tarball)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: x86_64-unknown-linux-gnu
release: 1.78.0
LLVM version: 18.1.2

Error output

   Compiling playground v0.0.1 (/playground)
error[E0116]: cannot define inherent `impl` for a type outside of the crate where the type is defined
 --> src/main.rs:6:1
  |
6 | impl Vec<usize> {}
  | ^^^^^^^^^^^^^^^ impl for type defined outside of crate.
  |
  = note: define and implement a trait or new type instead

error[E0599]: no method named `split` found for reference `&str` in the current scope
 --> src/main.rs:3:7
  |
3 |     x.split(" ");
  |       ^^^^^ method not found in `&str`

Some errors have detailed explanations: E0116, E0599.
For more information about an error, try `rustc --explain E0116`.
error: could not compile `playground` (bin "playground") due to 2 previous errors

Backtrace

<backtrace>

[workingjubilee]

...huh, the impl Vec<usize> causes a failure to find .split on str...

[estebank]

This happens because the query crate_inherent_impls returns a Result<&'tcx CrateInherentImpls, ErrorGuaranteed>, which means that when calling that query, if there's any error being propagated, we don't actually get the inherent impls. The options are to modify the existing query to never forward the errors (which would break the query caching mechanism, I believe) or add a second query that always succeeds, as a fallback to the fallible query so that we can get as many of the inherent impls as possible for the later resolutions.

[anthonydandrea]

I've never contributed to Rust OSS but if this may be first-time-contributor friendly, I'd be happy to give it a go. Any pointers of where to try changes beyond crate_inherent_impls would be appreciated!

[estebank]

@anthonydandrea the most esoteric thing you'll have to deal with is the query system, as there's a function crate_inherent_impls with a corresponding query crate_inherent_impls which is a way of encoding the contract of the "providers", so that you can define whether calls should get memoized/cached on-disk. Because we want errors to be properly tracked, you'd have to add a new query that always succeeds that isn't cached, that only gets called if the other query call fails. You probably can put that logic behind a method in TyCtxt which deals with the fall back and then call that new method from everywhere the query gets called today.

[estebank]

Current output is doing what was originally requested:

error[E0116]: cannot define inherent `impl` for a type outside of the crate where the type is defined
 --> src/main.rs:6:1
  |
6 | impl Vec<usize> {}
  | ^^^^^^^^^^^^^^^ impl for type defined outside of crate
  |
  = note: define and implement a trait or new type instead