Try to evalate obligation in fulfillment when we have no inference vars

[Aaron1011]

Previously, we required that the predicate be 'global', which also
ruled out type parameters. As long as we don't have any inference
variables (meaning that that the fulfillment will never need to
constrain any inferene variables), we can use the evaluate_obligation
query.

[rust-highfive]

r? @matthewjasper

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

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 121faca with merge 175a9cc1cf3acd27382e67c38be0fd0c341382d3...

[bors]

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

[rust-timer]

Queued 175a9cc1cf3acd27382e67c38be0fd0c341382d3 with parent 5d34076, future comparison URL.

[rust-timer]

Finished benchmarking try commit (175a9cc1cf3acd27382e67c38be0fd0c341382d3): comparison url.

Summary: This change led to significant mixed results 🤷 in compiler performance.

• Very large regression in instruction counts (up to 17.6% on full builds of wf-projection-stress-65510-check)
• Moderate improvement in instruction counts (up to -1.6% on full builds of unify-linearly-check)

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. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 74ee70c with merge 0d390589eed781c1e3aa3f8f045bf7f759912646...

[bors]

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

[rust-timer]

Queued 0d390589eed781c1e3aa3f8f045bf7f759912646 with parent 868c702, future comparison URL.

[rust-timer]

Finished benchmarking try commit (0d390589eed781c1e3aa3f8f045bf7f759912646): comparison url.

Summary: This change led to significant mixed results 🤷 in compiler performance.

• Very large regression in instruction counts (up to 17.6% on full builds of wf-projection-stress-65510-check)
• Moderate improvement in instruction counts (up to -1.6% on full builds of unify-linearly-check)

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. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[jackh726]

@Aaron1011 was this an alternative to #85868?

[Aaron1011]

This was an attempt at speeding up that PR - by itself, this PR doesn't fix any bugs. However, it appears that this approach actually hurts performance.