Add query to check for impossible predicates, use it to skip NoopMethodCall and Inline

[compiler-errors]

Fix a few cases where impossible founds can be found and can cause ICEs in codegen/linting.

Fixes#94999
Fixes#94680
Actually fixes#93008 this time

[rust-highfive]

r? @matthewjasper

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

[bors]

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

[cjgillot]

The query you created makes it seem like having impossible predicates is a property of an item. Should this check be done earlier, ie. at the beginning of typeck, in order to skip all the work of type checking and MIR building?

[cjgillot]

Could you rename the query to make the bool more explicit?
Something like item_has_impossible_predicates?

[cjgillot]

This paragraph is outdated.

[compiler-errors]

@cjgillot:

The query you created makes it seem like having impossible predicates is a property of an item. Should this check be done earlier, ie. at the beginning of typeck, in order to skip all the work of type checking and MIR building?

Yes, I agree that it's a property of the where clause on an item. However, they are allowed on the item with feature(trivial_bounds) and even in some cases without that feature (which, as a side note, I am probably going to put up a PR to warn on the latter cases).

The current behavior is to typecheck the items as if these predicates are true. I think we should at least continue to typecheck the items given the false predicates -- though I wouldn't be opposed to skipping mir-build (or at least all of mir-opt) in the case that they have impossible predicates.

This PR doesn't currently do that because I wanted to keep the affected compiler surface small, since it's the inliner that I have seen with the most ICEs due to calling codegen_fulfill_obligation on impossible predicates. Do you mind if I investigate additional changes (e.g. to skip all of MIR) in a follow-up PR?

[bors]

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

[compiler-errors]

@rustbot author

[compiler-errors]

@rustbot ready

r? rust-lang/compiler

[jackh726]

It's surprising to me that this doesn't just delegate to item_has_impossible_predicates_for_item.

The behavior these two are slightly different; could they be merged?

[compiler-errors]

I tried to before, but I had some regressions.

I think I could try again if I'm smarter with some things though... I'll investigate this weekend.

[jackh726]

Do you think we should land this in the meantime? If so, I think I'd like a FIXME added, but other than that, r=me

[compiler-errors]

It's not ridiculously critical, so I'll play around with it this weekend and either r=you with a better description of why they're different, or unify these two.

[compiler-errors]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 41ad624 with merge c55a268fc101a6e678d0894680e56e83673f0993...

[bors]

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

[rust-timer]

Queued c55a268fc101a6e678d0894680e56e83673f0993 with parent 18f314e, future comparison URL.

[rust-timer]

Finished benchmarking commit (c55a268fc101a6e678d0894680e56e83673f0993): comparison url.

Summary:

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

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	40	12	0	2	40
mean2	0.5%	1.4%	N/A	-1.2%	0.5%
max	0.9%	4.2%	N/A	-1.2%	0.9%

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. number of relevant changes↩

2. the arithmetic mean of the percent change↩

[compiler-errors]

Oof, that perf regression sucks. It's possibly because I'm elaborating the predicates always.

Testing the previous implementation for perf regression in #96382.

[compiler-errors]

This was superseded by #96806