delegation: remove method call generation

[aerooneqq]

This PR removes method call generation from delegations, now we always generate default call. Part of #118212.

We reuse methods probing engine for finding needed adjustments, thus extending number of supported cases. In this PR adjustments are applied to trait methods (was supported before) and static functions (new feature). Free functions can be supported later.

Example of static trait functions reuses that are now working:

trait Trait: Sized {
    fn static_value(_: Self) -> i32 { 1 }
    fn static_mut_ref(_: &mut Self) -> i32 { 2 }
    fn static_ref(_: &Self) -> i32 { 3 }
}

#[derive(Default)]
struct F;
impl Trait for F {}

struct S;

impl Trait for S {
    reuse <F as Trait>::{static_value, static_mut_ref, static_ref} { F }
}

fn main() {
    assert_eq!(S::static_ref(&S), 3);
    assert_eq!(S::static_mut_ref(&mut S), 2);
    assert_eq!(S::static_value(S), 1);
}

Finally this PR solves issues from parent generics propagation from #155906.

r? @petrochenkov

[petrochenkov]

Example of static trait functions reuses that are now working:

Is there specific motivation for this? I wouldn't expect this to work.

I actually think we need to change the design to ignore the target expression entirely if there's no self parameter.
In that case both static and non-static methods will be able to be delegated together.

reuse Trait::{method, static_fn} { self.field }

=>

fn method(&self, a: A, b: B) {
  self.field.method(a, b) // behavior, not exact desugaring
}

fn static_fn(a: A, b: B) {
  Trait::static_fn(a, b) // no self, so the target expr is ignored
}

[petrochenkov]

ignore the target expression entirely if there's no self parameter

Or rather generate something like

fn static_fn(a: A, b: B) {
  target_expr; // usually dead code and noop
  Trait::static_fn(a, b) // no self, so the target expr is ignored
}

to avoid issues like #154363 (comment).

[petrochenkov]

Isn't this the same thing as sig_id already evaluated above?

View changes since the review

[aerooneqq]

#118212 (comment)

We need path resolution (delegation.id) as we checking call.

[petrochenkov]

It's strange that this type annotation is required.

View changes since the review

[aerooneqq]

Seems like because it is first used in unwrap_or_else(|| self.check_expr_with_expectation(provided_arg, expectation));, if you insert a normal statement before (let _ = self.check_expr(provided_arg);) or remove unwrap_or_else then it infers type correctly.

[petrochenkov]

Can check_expr_method_call be reused here in some form?

I'd expect the logic here to contain two steps

• 1. determine that this ExprKind::Call needs to be treated as ExprKind::MethodCall
  • from HIR, if we merge these two ExprKind variants into one later, or from get_delegation_info now
• 2. reuse check_expr_method_call as closely as possible if it needs, or use check_argument_types otherwise

The second step shouldn't need to know anything about delegation.

View changes since the review