fix incorrect suggestions in private import diagnostic
Resolvesrust-lang/rust#156060.
1. In nested imports like `use two::{One, ...}`, the diagnostic suggested replacing the `One` with a multi-segment path of a different module, producing invalid code like `use crate::two::{one::One, Two}`. Skip it when `single_nested == true`.
2. Stop unconditionally skipping the first segment of `import.module_path`, which can produce incorrect paths in edition 2018 and later.
3. Mark the suggestion as "directly" instead of "through the re-export" when the import's source is the definition itself.
Fewer global node_id_to_def_id lookups
Several of these are unnecessary if we track the `LocalDefId` together with the `NodeId`. We can't remove the `NodeId` entirely, as it is needed for lints, but it's a useful refactoring for splitting node_id_to_def_id into a per-owner table in the future
r? @petrochenkov
Don't return dummy MacroData in `get_macro`
I was experimenting with tool attributes and ast manipulation, and wasted some time figuring out that this was happening. AFAIK all users of `get_macro` are expecting an actual macro (and none were reading the dummy MacroData) so there should be no change in behavior.
change field `tools` on `AttributeParser` to hold `&'tcx RegisteredTools`
Makes tools actually stored, and not just tool names
this was originally part of rust-lang/rust#155691 but was split out to make that PR smaller.
r? @petrochenkov
cc @JonathanBrouwer
Fix order-dependent visibility diagnostics
Fixesrust-lang/rust#40066.
Fixes https://github.com/rust-lang/rust/issues/109657.
Delay visibility path diagnostics until module collection has finished, so paths to later non-ancestor modules report E0742 instead of an unresolved path error.
Move `feature*` methods from `parse` mod to `errors` mod.
As the FIXME comment says, these no longer use `ParseSess` and so the `parse` mod is not a good place for them. The `errors` mod is a better home.
r? @TaKO8Ki
Suggest public re-exports when a private module makes an import path inaccessible
This is an attempt at solving rust-lang/rust#13065.
When a `use` path fails because it passes through a private module (E0603), and a public re-export of the target item exists elsewhere, the compiler will now suggest importing through that re-export instead.
For example, given:
```rust
mod outer {
pub use self::inner::MyStruct;
mod inner {
pub struct MyStruct;
}
}
use outer::inner::MyStruct; // error: module `inner` is private
```
the compiler will now suggest use `outer::MyStruct`; - the publicly accessible path - rather than just pointing at the private module definition and leaving the user to figure out the alternative.
When possible, relative paths are suggested, including those using `super` (currently capped at a maximum of one `super` path item).
The newly added test is parametrised by editions because of the change in behaviour around `crate::`-prefixed imports in edition 2018. Perhaps that’s an overkill – I’ll be happy to remove the variations for editions 2021 and 2024.
Closesrust-lang/rust#13065.
Cleanups to `AttributeExt`
r? @mejrs
- Makes some functions take `ast::Attribute` instead of `impl AttributeExt`
- Remove `deprecation_note` from `AttributeExt`, since the two implementations are basically seperate
privacy: Assert that compared visibilities are (usually) ordered
And make "greater than" (`>`) the new primary operation for comparing visibilities instead of "is at least" (`>=`).
Do not modify resolver outputs during lowering
Split from https://github.com/rust-lang/rust/pull/142830
I believe this achieves the same thing as https://github.com/rust-lang/rust/pull/153656 but in a much simpler way.
This PR forces AST->HIR lowering to stop mutating resolver outputs. Instead, it manages a few override maps that only live during lowering and are dropped afterwards.
r? @petrochenkov
cc @aerooneqq
Immediately feed visibility on DefId creation
This system was originally introduced in rust-lang/rust#121089
This PR was enabled by refactorings in rust-lang/rust#154945, because after that, the visibility feeding happens directly after the `DefId` creation, so we don't need to go through the intermediate hash table anymore
Should unblock rust-lang/rust#138995
Vadim Petrochenkov