Repository navigation
Error code E0116 causes high volume of incorrect compiler errors #125814
Copy link
Copy link
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
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:
-
If E0116 is found, just print that, and skip printing any other errors (preferred)
-
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>
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
workingjubilee commentedon Jun 1, 2024
...huh, the
impl Vec<usize>causes a failure to find.spliton str...estebank commentedon Jun 21, 2024
This happens because the query
crate_inherent_implsreturns aResult<&'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 commentedon 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_implswould be appreciated!estebank commentedon Jun 21, 2024
@anthonydandrea the most esoteric thing you'll have to deal with is the
querysystem, as there's a functioncrate_inherent_implswith a correspondingquery crate_inherent_implswhich 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 inTyCtxtwhich deals with the fall back and then call that new method from everywhere the query gets called today.estebank commentedon Dec 3, 2024
Current output is doing what was originally requested:
kei519 commentedon Dec 4, 2024
I want to try this, but like what tests should I add?
estebank commentedon Dec 4, 2024
@kei519 it would be adding a file with
in a
tests/ui/sub-directory (need to find an appropriate place), and then run./x.py test tests/ui --blessto create an.stderrfile. Be aware that the first compile will take a while, depending on your hardware, so make some tea :)kei519 commentedon Dec 5, 2024
Thank you! I'll try.
@rustbot claim
Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors…
Rollup merge of rust-lang#133890 - kei519:fix-125814, r=compiler-errors
Unrolled build for rust-lang#133890
Aditya-PS-05 commentedon Jan 9, 2025
@anthonydandrea , can you assign me this issue? I would love to solve it.
workingjubilee commentedon Jan 9, 2025
Resolved by #133890