Skip to content
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

Error code E0116 causes high volume of incorrect compiler errors #125814

Closed
anthonydandrea opened this issue May 31, 2024 · 10 comments
Closed

Error code E0116 causes high volume of incorrect compiler errors #125814

anthonydandrea opened this issue May 31, 2024 · 10 comments
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@anthonydandrea
Copy link

anthonydandrea commented May 31, 2024

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>

@anthonydandrea anthonydandrea added C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 31, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 31, 2024
@fmease fmease added A-diagnostics Area: Messages for errors, warnings, and lints D-confusing Diagnostics: Confusing error or lint that should be reworked. D-verbose Diagnostics: Too much output caused by a single piece of incorrect code. and removed I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ C-bug Category: This is a bug. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels May 31, 2024
@workingjubilee
Copy link
Member

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

@estebank
Copy link
Contributor

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
Copy link
Author

anthonydandrea commented Jun 21, 2024

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
Copy link
Contributor

@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
Copy link
Contributor

estebank commented Dec 3, 2024

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

@estebank estebank added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. and removed D-confusing Diagnostics: Confusing error or lint that should be reworked. D-verbose Diagnostics: Too much output caused by a single piece of incorrect code. labels Dec 3, 2024
@kei519
Copy link
Contributor

kei519 commented Dec 4, 2024

I want to try this, but like what tests should I add?

@estebank
Copy link
Contributor

estebank commented Dec 4, 2024

@kei519 it would be adding a file with

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

impl Vec<usize> {} //~ ERROR E0116

in a tests/ui/ sub-directory (need to find an appropriate place), and then run ./x.py test tests/ui --bless to create an .stderr file. Be aware that the first compile will take a while, depending on your hardware, so make some tea :)

@kei519
Copy link
Contributor

kei519 commented Dec 5, 2024

Thank you! I'll try.

@rustbot claim

kei519 added a commit to kei519/rust that referenced this issue Dec 5, 2024
… to check E0116 does not cause unrelated errors

rustc xxx (we do not know) to 1.82.0 emits unrelated errors when E0116
is present (see rust-lang#125814).

We do not know what caused and fixed it, but add a test to confirm rustc
does not cause the same error in the future.
fmease added a commit to fmease/rust that referenced this issue Dec 5, 2024
Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors to check E0116 does not cause unrelated errors

rustc xxx (we do not know) to 1.82.0 emits unrelated errors when E0116 is present (see rust-lang#125814).

We do not know what caused and fixed it, but add a test to confirm rustc does not cause the same error in the future.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Dec 5, 2024
Rollup merge of rust-lang#133890 - kei519:fix-125814, r=compiler-errors

Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors to check E0116 does not cause unrelated errors

rustc xxx (we do not know) to 1.82.0 emits unrelated errors when E0116 is present (see rust-lang#125814).

We do not know what caused and fixed it, but add a test to confirm rustc does not cause the same error in the future.
@Aditya-PS-05
Copy link
Contributor

@anthonydandrea , can you assign me this issue? I would love to solve it.

@workingjubilee
Copy link
Member

Resolved by #133890

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants