Change keyword order for `impl` restrictions
Based on rust-lang/rust#155222, this PR reorders keywords in trait definitions to group restrictions with visibility. It changes the order from `pub(...) const unsafe auto impl(...) trait Foo {...}` to `pub(...) impl(...) const unsafe auto trait Foo {...}`.
Tracking issue for restrictions: rust-lang/rust#105077
r? @Urgau
cc @jhpratt
delegation: support self ty propagation for functions in free to trait reuse
This PR adds support for self types specified in free to trait reuse. Up to this point we always generated `Self` despite the fact whether self type was specified or not. Now we use it in signature inheritance. Moreover we no more generate `Self` for static methods. Part of rust-lang/rust#118212.
```rust
trait Trait<T> {
fn foo<const B: bool>(&self) {}
fn bar() {}
}
impl<T> Trait<T> for usize {}
reuse <usize as Trait>::foo;
// Desugaring (no `Self` as usize is specified)
fn foo<T, const B: bool>(self: &usize) {
<usize as Trait::<T>>::foo::<B>(self)
}
reuse Trait::bar;
// Desugaring (no `Self` as static method)
fn bar<T>() {
Trait::<T>::bar(); //~ERROR: type annotations needed
}
```
r? @petrochenkov
Refactor FnDecl and FnSig non-type fields into a new wrapper type
#### Why this Refactor?
This PR is part of an initial cleanup for the [arg splat experiment](https://github.com/rust-lang/rust/issues/153629), but it's a useful refactor by itself.
It refactors the non-type fields of `FnDecl`, `FnSig`, and `FnHeader` into a new packed wrapper types, based on this comment in the `splat` experiment PR:
https://github.com/rust-lang/rust/pull/153697#discussion_r3004637413
It also refactors some common `FnSig` creation settings into their own methods. I did this instead of creating a struct with defaults.
#### Relationship to `splat` Experiment
I don't think we can use functional struct updates (`..default()`) to create `FnDecl` and `FnSig`, because we need the bit-packing for the `splat` experiment.
Bit-packing will avoid breaking "type is small" assertions for commonly used types when `splat` is added.
This PR packs these types:
- ExternAbi: enum + `unwind` variants (38) -> 6 bits
- ImplicitSelfKind: enum variants (5) -> 3 bits
- lifetime_elision_allowed, safety, c_variadic: bool -> 1 bit
#### Minor Changes
Fixes some typos, and applies rustfmt to clippy files that got skipped somehow.
Implement EII for statics
This PR implements EII for statics. I've tried to mirror the implementation for functions in a few places, this causes some duplicate code but I'm also not really sure whether there's a clean way to merge the implementations.
This does not implement defaults for static EIIs yet, I will do that in a followup PR
delegation: support proper interaction of user-specified args and impl Traits
This PR supports usages of user-specified args with impl Traits. When there are user-specified args in child we still need to generate synthetic generic params and use them during signature inheritance:
```rust
fn foo<T, const N: usize>(f: impl FnOnce()) {}
reuse foo::<String, 123> as bar;
//desugaring
fn bar<TSynth: impl FnOnce()>(f: _) {
foo::<String, 123>(f)
}
```
When inheriting predicates we process impl Trait ones, so we need generic params to instantiate them. Other approach may involve not generating synthetic generic params and try to filter out those predicates, but fairly generating synthetic params seems more consistent?.
Fixesrust-lang/rust#154780, part of rust-lang/rust#118212.
r? @petrochenkov
Fix `pattern_from_macro_note` for bit-or expr
This is a continuation of issue https://github.com/rust-lang/rust/issues/99380 (and pr https://github.com/rust-lang/rust/pull/124488) but covers bit-or pattern.
Essentially a `pat1 | pat2`, or any bit-or pattern used in a `$e:expr` was not firing the `.pattern_from_macro_note` diagnostic bc `ast::Expr::is_approximately_pattern()` did not cover bit-or.
The cover for bit-or is only added in `lower_expr_within_pat()`, otherwise doing it in `is_approximately_pattern()` would result in the suggestion `if (i + 2) = 2 => if let (i + 2) = 2` from `suggest_pattern_match_with_let()` (which is the only other place `ast::Expr::is_approximately_pattern()` is used from what i see).
resolves https://github.com/rust-lang/rust/issues/99380
refs https://github.com/rust-lang/rust/pull/124488
delegation: fix cycles during delayed lowering
This PR forces lowering of delayed owners after `hir_crate_items`, as some diagnostics use `hir_crate_items` which results in query cycle which is then hangs calling `def_path_str` again and again. Fixesrust-lang/rust#154169. Part of rust-lang/rust#118212.
r? @petrochenkov
Use fine grained component-wise span tracking in use trees
This often produces nicer spans and even doesn't need a Span field anymore (not that I expect the unused field to affect any perf, but still neat).
delegation: don't propagate synthetic params, remove lifetime hacks
Some small fixes after new delegation lowering was merged: remove lifetime hacks as now we get only early-bound lifetimes from generics, don't propagate synthetic generic params as now we know that they are synthetic. Fixesrust-lang/rust#143498. Part of rust-lang/rust#118212.
r? @petrochenkov
delegation: fix zero-args nested delegation ICE
This PR fixes an ICE when during lowering of nested delegation we need to access information about its parent, who is also inside body of another delegation. As a fix we lower delegation body even if there are no arguments in signature function, in this case we will see an error `this function takes 0 arguments but 1 argument was supplied`. Fixesrust-lang/rust#154332. Part of rust-lang/rust#118212.
r? @petrochenkov
Add macro matcher for `guard` fragment specifier
Tracking issue #153104
This PR implements a new `guard` macro matcher to match `if-let` guards (specifically [`MatchArmGuard`](https://github.com/rust-lang/reference/blob/50a1075e879be75aeec436252c84eef0fad489f4/src/expressions/match-expr.md#match-guards)). In the upcoming PR, we can use this new matcher in the `matches!` and `assert_matches!` macros to support their use with `if-let` guards. (see #152313)
The original `Expr` used to represent a guard has been wrapped in a new `Guard` type, allowing us to carry the span information of the leading `if` keyword. However, it might be even better to include the `if` keyword in the `Guard` type as well? I've left a FIXME comment in the code.
Add bit-or detection in lower expr within pattern.
Previously `pat1 | pat2` in `$e:expr` failed to trigger
`.pattern_from_macro_note` diagnostic bc
`ast::Expr::is_approximately_pattern()` did not cover bit-or.
Camille Gillot