Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them #133937

estebank · 2024-12-05T21:50:04Z

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 mods with parse errors.

Fix #97734.

rustbot · 2024-12-05T21:50:13Z

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2024-12-05T21:50:15Z

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Changes to the size of AST and/or HIR nodes.

cc @nnethercote

compiler/rustc_ast/src/ast.rs

rustbot · 2024-12-07T18:37:34Z

Changes to the size of AST and/or HIR nodes.

cc @nnethercote

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

petrochenkov · 2024-12-07T20:32:22Z

compiler/rustc_hir/src/hir.rs

@@ -3075,6 +3075,7 @@ pub enum ClosureBinder {
 pub struct Mod<'hir> {
    pub spans: ModSpans,
    pub item_ids: &'hir [ItemId],
+    pub had_parse_errors: Result<(), ErrorGuaranteed>,


Why is it needed in HIR? It's never used.

Good catch. Because it was public it didn't lint it was not being used.

compiler/rustc_resolve/src/lib.rs

…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.

…rs` has parse errors

davidtwco · 2024-12-12T11:58:38Z

@bors r+

bors · 2024-12-12T11:58:41Z

📌 Commit 27420c6 has been approved by davidtwco

It is now in the queue for this repository.

…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.

…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#130060 (Autodiff Upstreaming - rustc_codegen_llvm changes) - rust-lang#132038 (Add lint rule for `#[deprecated]` on re-exports) - rust-lang#133937 (Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them) - rust-lang#133942 (Clarify how to use `black_box()`) - rust-lang#134081 (Try to evaluate constants in legacy mangling) - rust-lang#134192 (Remove `Lexer`'s dependency on `Parser`.) - rust-lang#134209 (validate `--skip` and `--exclude` paths) Failed merges: - rust-lang#133099 (forbid toggling x87 and fpregs on hard-float targets) r? `@ghost` `@rustbot` modify labels: rollup

…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#133900 (Advent of `tests/ui` (misc cleanups and improvements) [1/N]) - rust-lang#133937 (Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them) - rust-lang#133938 (`rustc_mir_dataflow` cleanups, including some renamings) - rust-lang#134058 (interpret: reduce usage of TypingEnv::fully_monomorphized) - rust-lang#134130 (Stop using driver queries in the public API) - rust-lang#134140 (Add AST support for unsafe binders) - rust-lang#134229 (Fix typos in docs on provenance) r? `@ghost` `@rustbot` modify labels: rollup

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.

…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.

…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#133900 (Advent of `tests/ui` (misc cleanups and improvements) [1/N]) - rust-lang#133937 (Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them) - rust-lang#133938 (`rustc_mir_dataflow` cleanups, including some renamings) - rust-lang#134058 (interpret: reduce usage of TypingEnv::fully_monomorphized) - rust-lang#134130 (Stop using driver queries in the public API) - rust-lang#134140 (Add AST support for unsafe binders) - rust-lang#134229 (Fix typos in docs on provenance) r? `@ghost` `@rustbot` modify labels: rollup

rustbot assigned davidtwco Dec 5, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 5, 2024

This comment has been minimized.

Sign in to view

compiler-errors reviewed Dec 5, 2024

View reviewed changes

compiler/rustc_ast/src/ast.rs Outdated Show resolved Hide resolved

petrochenkov self-assigned this Dec 6, 2024

estebank force-pushed the silence-resolve-errors-from-mod-with-parse-errors branch from 71e5da5 to f9f0dbb Compare December 7, 2024 18:37

estebank force-pushed the silence-resolve-errors-from-mod-with-parse-errors branch from f9f0dbb to fa98e52 Compare December 7, 2024 18:57

estebank changed the title ~~Keep track of parse errors in mods and don't emit resolve errors for paths involving them~~ Keep track of parse errors in mods and don't emit resolve errors for paths involving them Dec 7, 2024

This comment has been minimized.

Sign in to view

petrochenkov reviewed Dec 7, 2024

View reviewed changes

petrochenkov removed their assignment Dec 7, 2024

estebank added 3 commits December 10, 2024 18:00

Add test for resolve errors caused by mod with parse errors

3f52583

Silence use foo::Bar; error if Bar isn't found in foo and `foo.…

27420c6

…rs` has parse errors

estebank force-pushed the silence-resolve-errors-from-mod-with-parse-errors branch from 8f7eff9 to 27420c6 Compare December 10, 2024 18:22

davidtwco approved these changes Dec 12, 2024

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 12, 2024

matthiaskrgr mentioned this pull request Dec 12, 2024

Rollup of 7 pull requests #134235

Closed

matthiaskrgr mentioned this pull request Dec 13, 2024

Rollup of 7 pull requests #134269

Merged

estebank mentioned this pull request Dec 13, 2024

The compiler gets hopelessly confused on enum S(usize); #80043

Open

bors merged commit c181026 into rust-lang:master Dec 14, 2024
6 checks passed

rustbot added this to the 1.85.0 milestone Dec 14, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them #133937

Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them #133937

estebank commented Dec 5, 2024 •

edited

Loading

rustbot commented Dec 5, 2024

rustbot commented Dec 5, 2024

This comment has been minimized.

rustbot commented Dec 7, 2024

This comment has been minimized.

petrochenkov Dec 7, 2024

estebank Dec 7, 2024

davidtwco commented Dec 12, 2024

bors commented Dec 12, 2024

Keep track of parse errors in mods and don't emit resolve errors for paths involving them #133937

Keep track of parse errors in mods and don't emit resolve errors for paths involving them #133937

Conversation

estebank commented Dec 5, 2024 • edited Loading

rustbot commented Dec 5, 2024

rustbot commented Dec 5, 2024

This comment has been minimized.

rustbot commented Dec 7, 2024

This comment has been minimized.

petrochenkov Dec 7, 2024

Choose a reason for hiding this comment

estebank Dec 7, 2024

Choose a reason for hiding this comment

davidtwco commented Dec 12, 2024

bors commented Dec 12, 2024

Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them #133937

Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them #133937

estebank commented Dec 5, 2024 •

edited

Loading