delegation: support proper interaction of user-specified args and impl Traits

[aerooneqq]

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:

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?.

Fixes #154780, part of #118212.

r? @petrochenkov

[rustbot]

HIR ty lowering was modified

cc @fmease

[petrochenkov]

r=me after squashing commits.
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[petrochenkov]

@bors delegate+

[rust-bors]

✌️ @aerooneqq, you can now approve this pull request!

If @petrochenkov told you to "r=me" after making some further change, then please make that change and post @bors r=petrochenkov.

[aerooneqq]

@bors r=petrochenkov

[rust-bors]

📌 Commit 51888a1 has been approved by petrochenkov

It is now in the queue for this repository.

[fmease]

This is not correct. It's injecting type parameters into a whole different context, it's uprooting a parameter from the def site and planting it at the use site (semi related: things like EarlyBinder solely exist to force people to think about this context change..).

I guess it only happens to work for delegation specifically because the generated delegate either reuses or has a copy of the generic parameters of the delegated function.

It's basically doing this:

fn f() {
    g();
    // ==>
    g::<T>(); // but `T` is not in scope!
}

fn g<T>() {}

Example fallout: #158152.

View changes since the review