diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2024-12-13 17:25:28 +0100 | 
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-12-13 17:25:28 +0100 | 
| commit | c1810269e98411ab546330b230ea20d9f632cd84 (patch) | |
| tree | f88ac5b11062842902daac2d725a09674ba20efe /compiler/rustc_mir_dataflow/src/framework/mod.rs | |
| parent | ab0d792d6e1f011458440c9cb678298d1f1170fd (diff) | |
| parent | 27420c69d830d7a32544dd42f40c757d9cb4e095 (diff) | |
| download | rust-c1810269e98411ab546330b230ea20d9f632cd84.tar.gz rust-c1810269e98411ab546330b230ea20d9f632cd84.zip  | |
Rollup merge of #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 https://github.com/rust-lang/rust/issues/97734.
Diffstat (limited to 'compiler/rustc_mir_dataflow/src/framework/mod.rs')
0 files changed, 0 insertions, 0 deletions
