Normalize obligation and expected trait_refs in confirm_poly_trait_refs

[compiler-errors]

Consolidate normalization the obligation and expected trait refs in confirm_poly_trait_refs. Also, always normalize these trait refs -- we were already normalizing the obligation trait ref when confirming closure and generator candidates, but this does it for fn pointer confirmation as well.

This presumably does more work in the case that the obligation's trait ref is already normalized, but we can see from the perf runs in #94070, it actually (paradoxically, perhaps) improves performance when paired with logic that normalizes projections in fulfillment loop.

[compiler-errors]

Forgot to remove a deleted test stderr..

[jackh726]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 3b1717eea1995cb31c0bca26cc734354930a93b3 with merge 8bd972219e2ab01d74589bbc494630993b93c5a2...

[bors]

☀️ Try build successful - checks-actions
Build commit: 8bd972219e2ab01d74589bbc494630993b93c5a2 (8bd972219e2ab01d74589bbc494630993b93c5a2)

[rust-timer]

Queued 8bd972219e2ab01d74589bbc494630993b93c5a2 with parent 30b3f35, future comparison URL.

[rust-timer]

Finished benchmarking commit (8bd972219e2ab01d74589bbc494630993b93c5a2): comparison url.

Summary: This benchmark run shows 1 relevant improvement 🎉 to instruction counts.

• Largest improvement in instruction counts: -3.3% on incr-patched: add static arr item builds of coercions debug

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

[compiler-errors]

Interesting to see that this alone doesn't really improve perf other than one case, but when paired with the other fulfillment normalization PRs, it causes many cases to no longer regress like 1%.

[jackh726]

I think we can land this separately, but I need to review later.

[compiler-errors]

Cool, I will make it not a draft and give it a real title and description, then.

[compiler-errors]

r? @jackh726 (just for tracking purposes, no rush on the review)

[jackh726]

This test highlights that something wonky is going on. It changes were we aren't able to normalize.

[compiler-errors]

Yeah, this is very interesting. Possibly due to changes in the ordering of resolving the inference variable in &mut <_ as Iterable>::Iterator<'a> and normalizing it. Now that we're eagerly normalizing the trait ref, we probably are substituting that value before we have a chance to unify the argument type with something else, possibly another projection type with an inference variable.

[jackh726]

@bors r+

[bors]

📌 Commit 3b1717eea1995cb31c0bca26cc734354930a93b3 has been approved by jackh726

[bors]

☔ The latest upstream changes (presumably #94134) made this pull request unmergeable. Please resolve the merge conflicts.

[jackh726]

@bors delegate+

[bors]

✌️ @compiler-errors can now approve this pull request

[compiler-errors]

@bors r=jackh726

[bors]

📌 Commit b59c958 has been approved by jackh726

[bors]

⌛ Testing commit b59c958 with merge a924ef7...

[bors]

☀️ Test successful - checks-actions
Approved by: jackh726
Pushing a924ef7 to master...

[rust-timer]

Finished benchmarking commit (a924ef7): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

[CAD97]

Just FYI: this likely changed inference to (correctly) accept more cases: https://www.reddit.com/r/rust/comments/t8ifzy/type_inference_fails_on_stable_but_succeeds_on/?utm_medium=android_app&utm_source=share

[compiler-errors]

@CAD97 this seems consistent with the changes in this this PR (and the issues I was originally focusing on when I first wrote this code in #93361). Thanks very much for noting this!