Keep track of parse errors in mods and don't emit resolve errors for paths involving them by estebank · Pull Request #133937 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation11 Commits3 Checks6 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

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.

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

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

This comment has been minimized.

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

estebank changed the titleKeep 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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

📌 Commit 27420c6 has been approved by davidtwco

It is now in the queue for this repository.

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 added a commit to matthiaskrgr/rust that referenced this pull request

Dec 12, 2024

…om-mod-with-parse-errors, r=davidtwco

Keep track of parse errors in mods 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 mods with parse errors.

Fix rust-lang#97734.

bors added a commit to rust-lang-ci/rust that referenced this pull request

Dec 13, 2024

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

bors added a commit to rust-lang-ci/rust that referenced this pull request

Dec 13, 2024

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

bors added a commit to rust-lang-ci/rust that referenced this pull request

Dec 13, 2024

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

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

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

Fix rust-lang#97734.

flip1995 pushed a commit to flip1995/rust that referenced this pull request

Dec 15, 2024

…om-mod-with-parse-errors, r=davidtwco

Keep track of parse errors in mods 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 mods with parse errors.

Fix rust-lang#97734.

flip1995 pushed a commit to flip1995/rust that referenced this pull request

Dec 15, 2024

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

Labels

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.