rust/tests/ui/resolve/parse-error-resolve.rs

mod parse_error;
use parse_error::Canonical; // ok, `parse_error.rs` had parse errors

fn main() {
    let _ = "" + 1; //~ ERROR E0369
    parse_error::Canonical.foo(); // ok, `parse_error.rs` had parse errors
}
Add test for resolve errors caused by mod with parse errors 2024-12-05 21:02:00 +00:00			`mod parse_error;`
Silence `use foo::Bar;` error if `Bar` isn't found in `foo` and `foo.rs` has parse errors 2024-12-05 21:47:06 +00:00			use parse_error::Canonical; // ok, `parse_error.rs` had parse errors
Add test for resolve errors caused by mod with parse errors 2024-12-05 21:02:00 +00:00
			`fn main() {`
			`let _ = "" + 1; //~ ERROR E0369`
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. 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 #97734. 2024-12-05 21:19:08 +00:00			parse_error::Canonical.foo(); // ok, `parse_error.rs` had parse errors
Add test for resolve errors caused by mod with parse errors 2024-12-05 21:02:00 +00:00			`}`