Eagerly drop higher-ranked type outlives obligations if satisfied by param env

[compiler-errors]

Attempts to satisfy TypeOutlives predicates using the param env, instead of unconditionally registering them in the infcx for later borrowck'ing. The first commit e176496 is the simpler attempt to fix this problem --and it fixes #97607 -- but only does so for TypeOutlives(_, RePlaceholder), so #86483 continues to fail.

The second commit 47a32b9 makes this logic slightly more complicated, but allows us to use for<'a> T: 'a to satisfy for<'a> T: 'region in general (including 'region = 'static), as long as it doesn't cause us to further constrain any region variables in T.

I'm still unsure if this is the right approach -- this is a generalization of the logic I think @oli-obk suggested here. Maybe it's overkill, and we can just search for exact matches in the param-env instead. I'd appreciate feedback.

I don't know who to r?, so I guess I'll just
r? @nikomatsakis
cc @rust-lang/types

Fixes #97607
Also converts tests from #88586, #86483 into passing.

[compiler-errors]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 47a32b9 with merge 49b46b6d0cc3b0f4ec5c5103ab51ee37cbdbd052...

[bors]

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

[rust-timer]

Queued 49b46b6d0cc3b0f4ec5c5103ab51ee37cbdbd052 with parent 546c826, future comparison URL.

[rust-timer]

Finished benchmarking commit (49b46b6d0cc3b0f4ec5c5103ab51ee37cbdbd052): comparison url.

Instruction count

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: 😿 relevant regressions found

	mean1	max	count2
Regressions 😿 (primary)	0.5%	1.5%	31
Regressions 😿 (secondary)	0.5%	0.8%	21
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	0.5%	1.5%	31

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 😿 relevant regression found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	2.3%	2.3%	1
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	N/A	N/A	0

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 may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²

[compiler-errors]

as expected... i wonder if we can employ some of the same heuristics used in impl matching.

[oli-obk]

Maybe it's overkill, and we can just search for exact matches in the param-env instead. I'd appreciate feedback.

I think I'd like that as the fix that we backport, as it's trivially correct and hopefully not a perf regression.

[compiler-errors]

Oh, yes, I totally forgot that @oli-obk mentioned we wanted to backport a fix, lol, or at least ensure a fix gets into the next beta. I can write up that solution easily.

[oli-obk]

Wait hold up. we already backported the revert, so there is no problem on beta. sorry for the false alarm!

[oli-obk]

We should still probably do that change to get it merged on nightly before the beta cutoff, out of the reasons I mentioned for the wrongly-assumed-beta-backport