[single_use_lifetimes]: Account for lifetime bounds
This PR makes `single_use_lifetimes` account for bounds on lifetime parameters, so a lifetime such as `'b` in `<'a, 'b: 'a>` is not treated as single-use just because its bound is stored separately from ordinary lifetime uses.
Fixesrust-lang/rust#153836
delegation: visit path under elided-infer lifetime rib
Up to this moment we processed delegation path under `LifetimeRibKind::Generics` which is not correct as we are processing generic args of a future call, not generic params. In this PR we visit path under
`LifetimeRibKind::Elided(LifetimeRes::Infer)`.
Fixesrust-lang/rust#156342. Part of rust-lang/rust#118212.
r? @petrochenkov
Avoid rustfix suggestions for macro-expanded unused imports
Avoid emitting rustfix suggestions for unused imports when the removal span is not directly editable.
Closesrust-lang/rust#147855
[style] rustfmt `match`es with comments in or-patterns
Using https://github.com/rust-lang/rustfmt/pull/6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
(Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
Implement pinned drop sugar
Implements `fn drop(&pin mut self)` as sugar for `Drop::pin_drop`.
The resolver recognizes `fn drop(&pin mut self)` syntactically in trait impls and performs lookup using the effective `pin_drop` name. AST lowering independently rechecks the syntactic sugar, validates that the resolved item belongs to the actual `Drop` lang trait, and emits HIR with ident `pin_drop` for accepted sugar. Existing type checking, Drop validation, drop glue, and direct-call checks remain unchanged.
Drop identity is checked during AST lowering through `tcx.lang_items().drop_trait()`, after resolver has performed the effective `pin_drop` lookup. The resolver does not need to know whether the trait is the actual `Drop` lang item, and it no longer passes marked impl item IDs to lowering.
This intentionally preserves the base pinned-drop behavior where `#[pin_v2]` types must use `pin_drop`, while non-`#[pin_v2]` types may still implement `pin_drop`.
r? @petrochenkov
## Related
https://github.com/rust-lang/rust/pull/144537https://github.com/rust-lang/rust/issues/130494
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
Using https://github.com/rust-lang/rustfmt/pull/6893, reformat the codebase. The result is that matches that *would have* been formatted under normal circumstances get their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
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.
Jacob Pratt