coercions reviews/misc whatevers

[BoxyUwU]

"remove normalize call"

Fixes #132765 in theory breaking as we might now treat some previously-ambig hr aliases as rigid when we shouldn't. we may want to explicitly normalize the coercion target in fcx.coerce like the new solver does

"leak check and lub for closure<->closure coerce-lubs"

Fixes rust-lang/trait-system-refactor-initiative#233

fn peculiar() -> impl Fn(u8) -> u8 {
    return |x| x + 1
}

the |x| x + 1 expr has a type of Closure(?31t) which we wind up inferring the RPIT to. The CoerceMany ret_coercion for the whole peculiar typeck has an expected type of RPIT (unnormalized). When we type check the return |x| x + 1 expr we go from the never type to Closure(?31t) which then participates in the ret_coercion giving us a coerce-lub(RPIT, Closure(?31t)).

Normalizing RPIT gives us some Closure(?50t) where ?31t and ?50t have been unified with ?31t as the root var. resolve_vars_if_possible doesn't resolve infer vars to their roots so these wind up with different structural identities so the fast path doesn't apply and we fall back to coercing to a fn ptr. cc #147193 which also fixes this

New solver probably just gets more inference variables here because canonicalization + generally different approach to normalization of opaques. Idk :3

This technically allows more code to compile (see the test using TAIT in the commit). I don't think this can be observed on stable though.

In theory this could break existing code that relied on coercing a closure to itself resulting in a fnptr. I don't expect this to really happen in practice and this is an "obvious" bug fix.

misc additional leak checks :)

We now leak check in a lot more places:

1. During subtyping occuring at coercion points. E.g. let a = b; will coerce b->a but if there's no coercion it just falls back to subtyping which is now leak checked.
2. Coercing closure->fnptr now leak checks
3. Coerce-lubbing fndef<->fndef now leak checks
4. Coerce-lubbing fndef<->closure or closure<->fndef now leak checks

For 1 and 2 this should in theory only affect dead code as inside of livecode the borrow checker will wind up checking these constraints anyway. For 2 specifically it's worth noting that we already leak check fndef->fnptr and fnptr->fnptr coercions on stable.

3 allows more code to compile. Previously by not leak checking we could wind up thinking two fndefs were equal and so avoid coercing to a fnptr. Then borrowck would wind up emitting an error due to incompatible binders. See tests/ui/coercion/leak_check_fndef_lub.rs which failed to compile before this PR.

3 and 4 both stop some code from compiling in cases where the coerce-lub can only succeed due to lub arbitrarily returning the lhs for binders instead of a true "lub". See the order_dependence_x tests in tests/ui/coercion/leak_check_lub_to_fnptr.rs. Note that for fnptr<->fnptr coerce-lubs we already leak check on stable preventing equivalent code from compiling

similar to 1/2, both 3 and 4 should in theory also cause some code to stop compiling as we will be leak checking in dead code where borrowck is unable to emit errors.

TODO: I need to add some more tests here and properly link to them I think

"account for safe target features in fndef<->closure and fndef<->fndef coerce-lubs"

We previously did not take safe target features into account when creating the fn sig for fndefs during fndef<->closure or fndef<->fndef coerce-lubs. We now do allowing coerce-lub to produce a safe fn pointer when fndefs with safe target features are involved. This is consistent with existing (non lub) coercion logic for fndef->fnptr which allows coercing to a safe fn pointer.

r? ghost

[BoxyUwU]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[rust-bors]

⌛ Trying commit f5ebf2e with merge 84addd3…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/18955853581