Unhelpful error spam after syntax error. #97734
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
A-parser
Area: The parsing of Rust source code to an AST
A-resolve
Area: Name/path resolution done by `rustc_resolve` specifically
D-verbose
Diagnostics: Too much output caused by a single piece of incorrect code.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
kevincox
added
A-diagnostics
|
Perhaps we can limit the number of E0425 to emit here.. |
|
In this case 1 is already to many. It might be a mitigation but it doesn't really solve the problem. It seems that that error should only be emitted if the module was evaluated successfully. Otherwise it will be full of false positives. |
estebank
added
D-verbose
|
CC #74863, similar case, just in value scope. |
estebank
added a commit
to estebank/rust
that referenced
this issue
Dec 5, 2024
…r paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion. Fix rust-lang#97734.
estebank
added a commit
to estebank/rust
that referenced
this issue
Dec 5, 2024
…r paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion. Fix rust-lang#97734.
estebank
added a commit
to estebank/rust
that referenced
this issue
Dec 7, 2024
…r paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion. Fix rust-lang#97734.
estebank
added a commit
to estebank/rust
that referenced
this issue
Dec 7, 2024
…r paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion. Fix rust-lang#97734.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 12, 2024
…om-mod-with-parse-errors, r=davidtwco Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around in the HIR and mark its `DefId` in the `Resolver`. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by expansion of `mod`s with parse errors. Fix rust-lang#97734.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 13, 2024
…om-mod-with-parse-errors, r=davidtwco Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around in the HIR and mark its `DefId` in the `Resolver`. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by expansion of `mod`s with parse errors. Fix rust-lang#97734.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 14, 2024
Rollup merge of rust-lang#133937 - estebank:silence-resolve-errors-from-mod-with-parse-errors, r=davidtwco Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around in the HIR and mark its `DefId` in the `Resolver`. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by expansion of `mod`s with parse errors. Fix rust-lang#97734.
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this issue
Dec 15, 2024
…th-parse-errors, r=davidtwco Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around in the HIR and mark its `DefId` in the `Resolver`. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by expansion of `mod`s with parse errors. Fix rust-lang/rust#97734.
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Dec 15, 2024
…r paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion. Fix rust-lang#97734.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Given the following code:
ui.rsmodule.(I don't appear to be able to reproduce this in the playground because it appears to require multiple files.)
The current output is:
Ideally the output should look like:
The hundreds of errors about things functions not existing because they were after a syntax error in the file are not helpful.
#27189 would mitigate this issue but the current behaviour is pretty poor either way.
The text was updated successfully, but these errors were encountered: