Privacy: move macros handling to early stage
The patch moves effective visibility computation for macros from `rustc_privacy` to `rustc_resolve`. It will enable this optimization: https://github.com/rust-lang/rust/pull/156228.
However, I found some problems with macro handling while I was doing this. The current implementation was written ~6 years ago and checks the reachability of a definition from a macro by nominal visibility. In general this is incorrect.
For example, in the current implementation modules are not traversed if their nominal visibility is less then the nominal visibility of a module defining macro: https://github.com/rust-lang/rust/blob/29b7590130c83542a095cdf1323ed0f78eec2bb8/compiler/rustc_privacy/src/lib.rs#L618-L626
As a result, in order to compile code like `tests/ui/definition-reachable/auxiliary/field-method-macro.rs`. we have to additionally traverse types of adt fields: https://github.com/rust-lang/rust/blob/29b7590130c83542a095cdf1323ed0f78eec2bb8/compiler/rustc_privacy/src/lib.rs#L628-L638
This is a hack and the proper solution would be to check definitions with `EffectiveVisibilities::is_reachable`. I haven’t done this yet, as it would start to trigger many lints as more items become reachable. I think it’s better to leave the change to another commit.
r? @petrochenkov
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.
Jonathan Brouwer