Erase trivial caller-bounds when typechecking MIR after optimizations

[compiler-errors]

Fixes an ICE when inlining this code (with -Zmir-opt-level=3):

trait Factory<T> {
    type Item;
}

struct IntFactory;

impl<T> Factory<T> for IntFactory {
    type Item = usize;
}

fn foo<T>() where IntFactory: Factory<T> {
    let mut x: <IntFactory as Factory<T>>::Item = bar::<T>();
}

#[inline]
fn bar<T>() -> <IntFactory as Factory<T>>::Item {
    0usize
}

Specifically, inside of bar, we normalize <IntFactory as Factory<T>>::Item to usize, but we cannot do the same inside of foo, because param-env candidates have precedence over impl candidates when satisfying the projection. This usually isn't a problem, but becomes one when we inline bar into baz and cannot unify usize with <IntFactory as Factory<T>>::Item.

This attempts to solve the issue by filtering thru the ParamEnv and removing any predicates that are "trivial" -- that is, that are satisfied by the ParamEnv when the bound is removed from the ParamEnv's caller bounds. This ensures that we never allow a trivial <Ty as Trait> predicate in the ParamEnv interfere with projection normalization during codegen.

---

cc: #91743 (comment)
cc: @cjgillot since it helps a get rid of a few (but not all) ICEs seen from nalgebra-v0.21.1 in #91743

NOTE: this is kinda a hack, a super heavy hammer that I'm not sure if we should implement in the first place. I'm open to closing this piece of garbage out for a better brainstorming session for how to handle ambiguities as noted above. 😄

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[compiler-errors]

r? @nikomatsakis since this has to do with how we normalize projection types, but feel free to send this to someone else

[oli-obk]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 240e56189205b2a30bd84601cbcbede36b33812b with merge 689f51a2c72ad2d2c5eb3719fa78e8e209214e64...

[bors]

💔 Test failed - checks-actions

[compiler-errors]

lol let me fix that

[tmiasko]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 244a73c with merge dc5b9515ae3599b4dc5438f23aee3092e95c2543...

[bors]

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

[rust-timer]

Queued dc5b9515ae3599b4dc5438f23aee3092e95c2543 with parent 3d127e2, future comparison URL.

[rust-timer]

Finished benchmarking commit (dc5b9515ae3599b4dc5438f23aee3092e95c2543): 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.

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]

@rustbot label -S-waiting-on-author

[oli-obk]

param-env candidates have precedence over impl candidates when satisfying the projection.

could we flip this in reveal_all mode?

[compiler-errors]

I could try that, shouldn't be too hard.

[nikomatsakis]

Hmm, this seems like a good thing to talk over, @compiler-errors. If it works for you, maybe schedule something at https://calendly.com/nikomatsakis/ ?

[compiler-errors]

So after discussing with @nikomatsakis, this PR is probably not the right way to go through with this. We discussed a few other options, which I'll likely test out and maybe put up for review. I'll mark this one as experimental.

@rustbot -S-waiting-on-review +S-experimental

[compiler-errors]

lol whoops

@rustbot label -S-waiting-on-review +S-experimental

[compiler-errors]

This is probably(?) fixed by @cjgillot's finished mir-inliner PR. I will add a test later anyways.