e2a0e387a4
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. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
clippy-utils
Helpful tools for writing lints, provided as they are used in Clippy.
Usage
This crate is only guaranteed to build with this nightly toolchain:
nightly-2024-11-28
To use clippy-utils in your lint, add the following to your Cargo.toml:
clippy_utils = "0.1.XY"
XY is the version of the nightly toolchain above and can be determined with rustc +nightly-YYYY-MM-DD -V.
⚠️ Stability ⚠️
No stability guarantees are made for this crate! Use at your own risk.
Function signatures can change or be removed without replacement without any prior notice.
LICENSE
Copyright 2014-2024 The Rust Project Developers
Licensed under the Apache License, Version 2.0 <https://www.apache.org/licenses/LICENSE-2.0> or the MIT license <https://opensource.org/licenses/MIT>, at your option. Files in the project may not be copied, modified, or distributed except according to those terms.