Delegation implementation: step 1

See rust-lang#118212 for more details.

r? `@petrochenkov`

…ov,lcnr

Delegation implementation: step 1

See rust-lang#118212 for more details.

r? `@petrochenkov`

…,lcnr

Delegation implementation: step 1

See rust-lang#118212 for more details.

r? `@petrochenkov`

…,lcnr

Delegation implementation: step 1

See rust-lang#118212 for more details.

r? `@petrochenkov`

…,lcnr

Delegation implementation: step 1

See rust-lang#118212 for more details.

r? `@petrochenkov`

Delegation implementation: step 1

See rust-lang/rust#118212 for more details.

r? `@petrochenkov`

Delegation implementation: step 1

See rust-lang/rust#118212 for more details.

r? `@petrochenkov`

delegation: Support renaming, and async, const, extern "ABI" and C-variadic functions

Also allow delegating to functions with opaque types (`impl Trait`).
The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created, which seems like a reasonable behavior.
(Such delegation items will cause query cycles when used in trait impls, but it can be fixed later.)

Part of rust-lang#118212.

delegation: Support renaming, and async, const, extern "ABI" and C-variadic functions

Also allow delegating to functions with opaque types (`impl Trait`).
The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created, which seems like a reasonable behavior.
(Such delegation items will cause query cycles when used in trait impls, but it can be fixed later.)

Part of rust-lang#118212.

delegation: Support renaming, and async, const, extern "ABI" and C-variadic functions

Also allow delegating to functions with opaque types (`impl Trait`).
The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created, which seems like a reasonable behavior.
(Such delegation items will cause query cycles when used in trait impls, but it can be fixed later.)

Part of rust-lang#118212.

delegation: Support renaming, and async, const, extern "ABI" and C-variadic functions

Also allow delegating to functions with opaque types (`impl Trait`).
The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created, which seems like a reasonable behavior.
(Such delegation items will cause query cycles when used in trait impls, but it can be fixed later.)

Part of rust-lang/rust#118212.

delegation: Support renaming, and async, const, extern "ABI" and C-variadic functions

Also allow delegating to functions with opaque types (`impl Trait`).
The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created, which seems like a reasonable behavior.
(Such delegation items will cause query cycles when used in trait impls, but it can be fixed later.)

Part of rust-lang/rust#118212.

delegation: Implement list delegation

```rust
reuse prefix::{a, b, c};
```

Using design described in rust-lang/rfcs#3530 (comment) (the lists are desugared at macro expansion time).
List delegations are expanded eagerly when encountered, similarly to `#[cfg]`s, and not enqueued for later resolution/expansion like regular macros or glob delegation (rust-lang#124135).

Part of rust-lang#118212.

delegation: Implement glob delegation

Support delegating to all trait methods in one go.
Overriding globs with explicit definitions is also supported.

The implementation is generally based on the design from rust-lang/rfcs#3530 (comment), but unlike with list delegation in rust-lang#123413 we cannot expand glob delegation eagerly.
We have to enqueue it into the queue of unexpanded macros (most other macros are processed this way too), and then a glob delegation waits in that queue until its trait path is resolved, and enough code expands to generate the identifier list produced from the glob.

Glob delegation is only allowed in impls, and can only point to traits.
Supporting it in other places gives very little practical benefit, but significantly raises the implementation complexity.

Part of rust-lang#118212.

delegation: Implement glob delegation

Support delegating to all trait methods in one go.
Overriding globs with explicit definitions is also supported.

The implementation is generally based on the design from rust-lang/rfcs#3530 (comment), but unlike with list delegation in rust-lang#123413 we cannot expand glob delegation eagerly.
We have to enqueue it into the queue of unexpanded macros (most other macros are processed this way too), and then a glob delegation waits in that queue until its trait path is resolved, and enough code expands to generate the identifier list produced from the glob.

Glob delegation is only allowed in impls, and can only point to traits.
Supporting it in other places gives very little practical benefit, but significantly raises the implementation complexity.

Part of rust-lang#118212.

Rollup merge of rust-lang#124135 - petrochenkov:deleglob, r=fmease

delegation: Implement glob delegation

Support delegating to all trait methods in one go.
Overriding globs with explicit definitions is also supported.

The implementation is generally based on the design from rust-lang/rfcs#3530 (comment), but unlike with list delegation in rust-lang#123413 we cannot expand glob delegation eagerly.
We have to enqueue it into the queue of unexpanded macros (most other macros are processed this way too), and then a glob delegation waits in that queue until its trait path is resolved, and enough code expands to generate the identifier list produced from the glob.

Glob delegation is only allowed in impls, and can only point to traits.
Supporting it in other places gives very little practical benefit, but significantly raises the implementation complexity.

Part of rust-lang#118212.

…etrochenkov

Delegation: support coercion for target expression

(solves rust-lang#118212 (comment))

The implementation consist of 3 parts. Firstly, method call is generated instead of fully qualified call in AST->HIR lowering if there were no generic arguments or `Qpath` were provided. These restrictions are imposed due to the loss of information after desugaring. For example in

```rust
trait Trait {
  fn foo(&self) {}
}

reuse <u8 as Trait>::foo;
```

We would like to generate such a code:

```rust
fn foo<u8: Trait>(x: &u8) {
  x.foo(x)
}
```

however, the signature is inherited during HIR analysis where `u8` was discarded.

Secondly, traits found in the callee path are also added to `trait_map`. This is done to avoid the side effects of converting body into method calls:

```rust
mod inner {
    pub trait Trait {
      fn foo(&self) {}
    }
}

reuse inner::Trait::foo; // Ok, `Trait` is in scope for implicit method call.
```

Finally, applicable candidates are filtered with pre-resolved method during method lookup.

P.S In the future, we would like to avoid restrictions on the callee path by `Self` autoref/autoderef in fully qualified calls, but at the moment it didn't work out.

r? `@petrochenkov`

…ompiler-errors

Delegation: support coercion for target expression

(solves rust-lang#118212 (comment))

The implementation consist of 2 parts. Firstly, method call is generated instead of fully qualified call in AST->HIR lowering if there were no generic arguments or `Qpath` were provided. These restrictions are imposed due to the loss of information after desugaring. For example in

```rust
trait Trait {
  fn foo(&self) {}
}

reuse <u8 as Trait>::foo;
```

We would like to generate such a code:

```rust
fn foo<u8: Trait>(x: &u8) {
  x.foo(x)
}
```

however, the signature is inherited during HIR analysis where `u8` was discarded.

Then, we probe the single pre-resolved method.

P.S In the future, we would like to avoid restrictions on the callee path by `Self` autoref/autoderef in fully qualified calls, but at the moment it didn't work out.

r? `@petrochenkov`

Rollup merge of rust-lang#126699 - Bryanskiy:delegation-coercion, r=compiler-errors

Delegation: support coercion for target expression

(solves rust-lang#118212 (comment))

The implementation consist of 2 parts. Firstly, method call is generated instead of fully qualified call in AST->HIR lowering if there were no generic arguments or `Qpath` were provided. These restrictions are imposed due to the loss of information after desugaring. For example in

```rust
trait Trait {
  fn foo(&self) {}
}

reuse <u8 as Trait>::foo;
```

We would like to generate such a code:

```rust
fn foo<u8: Trait>(x: &u8) {
  x.foo(x)
}
```

however, the signature is inherited during HIR analysis where `u8` was discarded.

Then, we probe the single pre-resolved method.

P.S In the future, we would like to avoid restrictions on the callee path by `Self` autoref/autoderef in fully qualified calls, but at the moment it didn't work out.

r? `@petrochenkov`