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
Use per-parent disambiguators everywhere
This PR addressing the following concerns about per-parent disambiguators (rust-lang/rust#153955):
- DisambiguatorState is removed, PerParentDisambiguatorState is now used everywhere,
- Steals were removed from every per-parent disambiguator in resolver,
- It adds `parent` field in `PerParentDisambiguatorState` in `#[cfg(debug_assertions)]` for asserting that per-parent disambiguator corresponds to the same `LocalDefId` which is passed into `create_def`,
- ~Removes `Disambiguator` trait replacing it with `Disambiguator` enum, with this change we no longer expose `next` method (as trait should be public otherwise the warning will be emitted). It may affect perf in a negative way though.~
~Those changes should not fix perf issues that were [reported](https://github.com/rust-lang/rust/pull/153955#issuecomment-4269223191), perf run that was attempted [before](https://github.com/rust-lang/rust/pull/153955#issuecomment-4214516698) showed much better results. Performance can be probably fixed by removing per-parent disambiguators replacing them with a single one as it was before, then it will be passed to AST -> HIR lowering and modified. For delayed owners we can store ~followup disambiguators as it was in the beginning of the rust-lang/rust#153955~ per-parent disambiguators. This solution should save achievements from rust-lang/rust#153955 (removed `DefPathData` variants).
However, I would prefer to keep per-parent disambiguators as it seems a better architectural solution for me.~
r? @petrochenkov
cc @oli-obk
Modify error message of importing inherent associated items when `#[feature(import_trait_associated_functions)]` is enabled
Fixesrust-lang/rust#148009
This PR improves the diagnostic for importing inherent associated items from a struct or union when
`#[feature(import_trait_associated_functions)]` (rust-lang/rust#134691) is enabled.
Previously, this would result in a "not a module" error. This change provides a more specific error message clarifying that only trait associated items can be imported, while inherent associated items remain ineligible for import.
Enums are currently excluded from this change because their variants are valid import targets and require distinct handling.
Merge BuildReducedGraphVisitor into DefPathVisitor
These two visitors run right after each other on the same immutable AST. There's also a hash map for transferring the TyCtxtFeed created in the def collector to the BRG when it visits the same items. There are possibly more avenues for sharing logic, but I want to keep this PR simple.
only opening for perf runs for now. I'm still investigating how to ensure that future changes don't introduce subtle bugs by forgetting that def collection and reduced graph building are one pass now
Best reviewed commit-by-commit. I took a lot of care for making the individual changes reviewable, but all the `Merge *` commits aren't able to compile libcore until the last one.
Jacob Pratt