cc rust-lang/rust#148190 @flip1995 @RalfJung
This is a bit of a hack in that it hardcodes the list of crates with
stability attributes. This shouldn't be a big deal since that isn't a
set that changes very frequently and an internal lint could detect when
that happens.
The `fixme`s added aren't new issues and shouldn't get in the way of
unblocking the upstream issue.
changelog: none
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
When mgca is enabled, const rhs's that are paths may have false
negatives with the lints in non_copy_const.rs. But these should probably
be using the trait solver anyway, and it only happens under mgca.
Fixrust-lang/rust-clippy#15943
```rust
pub fn from_days(days: u8) -> Duration {
Duration::from_secs(86400 * u64::from(days))
}
```
An initial foundation that can be used for future improvements. It is
been a while since I touched Clippy so feel free to indicate better
designs if applicable.
Looks like https://github.com/rust-lang/rust-clippy/pull/15342 will help
but it is unclear when it will be finished. This PR provides a partial
solution for the current time.
changelog: [`arithmetic_side_effects`]: Consider type conversion that
won't overflow
fix: Only special case single line item attribute suggestions
`rustc` currently special cases suggestions to add [`#[derive(_)]\n` and other attributes](https://github.com/rust-lang/rust/blob/dc1feabef242259d61bd930713de3250577c1c71/compiler/rustc_errors/src/emitter.rs#L2288C36-L2288C72), to add more context to the suggestions.
> // The suggestion adds an entire line of code, ending on a newline, so we'll also
> // print the *following* line, to provide context of what we're advising people to
> // do. Otherwise you would only see contextless code that can be confused for
> // already existing code, despite the colors and UI elements.
> // We special case `#[derive(_)]\n` and other attribute suggestions, because those
> // are the ones where context is most useful.
This special case is a bit broad at the moment and applies to suggestions just to add an attribute, as well as suggestions that contain an attribute and other code, i.e.
```rust
#[derive(Clone)]
```
and
```rust
#[cfg(not(test))]
impl Default for NewWithCfg {
fn default() -> Self {
Self::new()
}
}
```
In the latter case, adding a line for context after the suggestion doesn't provide much benefit. Example:
This PR makes it so that this special case only applies to suggestions that just add an attribute and nothing else. This will also make `rustc`'s output match `annotate-snippets`.
Implement pin-project in pattern matching for `&pin mut|const T`
This PR implements part of rust-lang/rust#130494. It supports pin-project in pattern matching for `&pin mut|const T`.
~Pin-projection by field access (i.e. `&pin mut|const place.field`) is not fully supported yet since pinned-borrow is not ready (rust-lang/rust#135731).~
CC ``````@traviscross``````
Samuel Tardieu