rustc_on_unimplemented: introduce format specifiers
...as printing options for the annotated item.
See also the test and dev guide prose. This only affects rustc_on_unimplemented, not (yet) the other diagnostic attributes. I plan to do that in some later PR.
```rust
#![feature(rustc_attrs)]
#[rustc_on_unimplemented(
message = "normal: {This}, path: {This:path}, resolved: {This:resolved}"
)]
pub trait Trait<'lifetime, const CONST_GENERIC: usize, A, B> where A: Send {}
```
will do:
```
normal: Trait, path: Trait<'lifetime, CONST_GENERIC, A, B>, resolved: Trait<'_, 6, u8, _>
```
[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.
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.
Add `Drop::pin_drop` for pinned drops
This PR is part of the `pin_ergonomics` experiment (the tracking issue is rust-lang/rust#130494). It allows implementing `Drop` with a pinned `self` receiver, which is required for safe pin-projection.
Implementations:
- [x] At least and at most one of `drop` and `pin_drop` should be implemented.
- [x] No direct call of `drop` or `pin_drop`. They should only be called by the drop glue.
- [x] `pin_drop` must and must only be used with types that support pin-projection (i.e. types with `#[pin_v2]`).
- [ ] Allows writing `fn drop(&pin mut self)` and desugars to `fn pin_drop(&pin mut self)`. (Will be in the next PRs)
When an unconstrained type or lifetime parameter is detected in an
`impl`, provide more specific help based on its usage:
- If the parameter is entirely unused, suggest removing it.
- If it is used in the `impl` body but not the `Self` type, suggest
including it in the `Self` type and the struct definition.
This also adds a comprehensive UI test for these cases.
Remove unused spans from AttributeKind
Recently I noticed some spans in diagnostic attributes were never used. I went through and checked the other variants too.
Clean up some traits
I was looking at various traits and found some unnecessary trait bounds, and some unnecessary traits. Details in individual commits.
r? @Nadrieril
Specifically:
- `HashStable` -> `StableHash` (trait)
- `HashStable` -> `StableHash` (derive)
- `HashStable_NoContext` -> `StableHash_NoContext` (derive)
Note: there are some names in `compiler/rustc_macros/src/hash_stable.rs`
that are still to be renamed, e.g. `HashStableMode`.
Part of MCP 983.
Simplify `HashStable`
This PR:
- Simplifies the `HashStable` trait, by moving its generic parameter from the trait to its single method.
- Eliminates the need for the non-obvious `derive(HashStable)`/`derive(HashStable_Generic)` distinction.
- Reduces the need for, and clarifies, the non-obvious `derive(HashStable)`/`derive(HashStable_NoContext)` distinction.
r? @fee1-dead
`std::hash::Hash` looks like this:
```
pub trait Hash {
fn hash<H>(&self, state: &mut H)
where H: Hasher;
...
}
```
The method is generic.
In contrast, `HashStable` looks like this:
```
pub trait HashStable<Hcx> {
fn hash_stable(&self, hcx: &mut Hcx, hasher: &mut StableHasher);
}
```
and impls look like this (in crates upstream of `rustc_middle`):
```
impl<Hcx: HashStableContext> HashStable<Hcx> for Path {
fn hash_stable(&self, hcx: &mut Hcx, hasher: &mut StableHasher) {
...
}
}
```
or this (in `rustc_middle` and crates downstream of `rustc_middle`):
```
impl<'tcx> HashStable<StableHashingContext<'tcx>> for rustc_feature::Features {
fn hash_stable(&self, hcx: &mut StableHashingContext<'tcx>, hasher: &mut StableHasher) {
...
}
}
```
Differences to `std::hash::Hash`:
- The trait is generic, rather than the method.
- The way impls are written depends their position in the crate graph.
- This explains why we have both `derive(HashStable)` and
`derive(HashStable_Generic)`. The former is for the
downstream-of-`rustc_middle` case, the latter is for the upstream of
`rustc_middle` case.
Why the differences? It all boils down to `HashStable` and
`HashStableContext` being in different crates. But the previous commit
fixed that, which means `HashStable` can be simplified to this, with a
generic method:
```
pub trait HashStable {
fn hash_stable<Hcx: HashStableContext>(&self, hcx: &mut Hcx, hasher: &mut StableHasher);
}
```
and all impls look like this:
```
impl HashStable for Path {
fn hash_stable<Hcx: HashStableContext>(&self, hcx: &mut Hcx, hasher: &mut StableHasher) {
...
}
}
```
Other consequences:
- `derive(HashStable_Generic)` is no longer needed; `derive(HashStable)`
can be used instead.
- In this commit, `derive(HashStable_Generic` is made a synonym of
`derive(HashStable)`. The next commit will remove this synonym,
because it's a change that touches many lines.
- `#[stable_hash_generic]` is no longer needed (for `newtype_index`);
`#[stable_hash]` can be used instead.
- `#[stable_hash_no_context]` was already a synonym of
`#[stable_hash_generic]`, so it's also removed in favour of just
`#[stable_hash]`.
- The difference between `derive(HashStable)` and
`derive(HashStable_NoContext)` now comes down to the difference
between `synstructure::AddBounds::Generics` and
`synstructure::AddBounds::Fields`, which is basically "vanilla derive"
vs "(near) perfect derive".
- I have improved the comments on `HashStableMode` to better
explaining this subtle difference.
- `rustc_middle/src/ich/impls_syntax.rs` is no longer needed; the
relevant impls can be defined in the crate that defines the relevant
type.
- Occurrences of `for<'a> HashStable<StableHashingContext<'a>>` are
replaced with with `HashStable`, hooray.
- The commit adds a `HashStableContext::hashing_controls` method, which
is no big deal. (It's necessary for `AdtDefData::hash_stable`, which
calls `hashing_controls` and used to have an `hcx` that was a
concrete `StableHashingContext` but now has an `hcx` that is just
`Hcx: HashStableContext`.)
Overall this is a big simplification, removing a lot of confusing
complexity in stable hashing traits.
This puts it in the same crate as the `HashStable` and `ToStableHasher`
traits. This requires introducing three types `RawSpan`, `RawDefId` and
`RawDefPathHash` to work around the fact that `rustc_data_structures`
is upstream of `rustc_span` and so doesn't have access to `Span`,
`DefId`, and `DefPathHash`. This is a bit ugly but is worth it because
moving `HashStableContext` enables big cleanups across many crates in
subsequent commits.
Change `ItemKind::Trait` to a field variant.
This changes `ItemKind::Trait` from an octuple(!!) to an enum variant with fields. Their names were chosen to match up with existing usage and minimize renaming.
I'm leaning towards renaming `ident` to `name` as well; let me know if that's desired.
Remove `AttributeLintKind`
Part of https://github.com/rust-lang/rust/issues/153099.
The `AttributeLintKind` type is finally gone! \o/
Diff is this big because I moved a file and a lot of `Diagnostic` types. :')
r? @JonathanBrouwer
Jonathan Brouwer