Avoid reporting overflow in is_impossible_method

[compiler-errors]

Fixes#100620

We're evaluating a new predicate in a different param-env than it was checked during typeck, so be more careful about handling overflow errors. Instead of using FulfillmentCtxt, using InferCtxt::evaluate_obligation by itself will give us back the overflow error, so we can throw it away properly.

This may give us more false-positives, but it doesn't regress the <HashMap as Iterator>::rev example that originally motivated adding is_impossible_method in the first place.

[rust-highfive]

r? @jackh726

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

[notriddle]

r? compiler

[weiznich]

Any chance to merge this soon, as this is currently blocking a diesel release?

[oli-obk]

@bors r+

[bors]

📌 Commit c4a5b14 has been approved by oli-obk

It is now in the queue for this repository.

[compiler-errors]

@bors p=1

this is also causing errors on diesel perf runs, so bumping the prio a bit

[bors]

⌛ Testing commit c4a5b14 with merge 983f4da...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 983f4da to master...

[rust-timer]

Finished benchmarking commit (983f4da): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	0.7%	[0.6%, 0.8%]	6
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-0.5%	[-0.6%, -0.4%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[-0.6%, 0.8%]	8

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.2%	[2.2%, 6.8%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-2.8%, -2.8%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.4%, 2.4%]	1
Improvements ✅ (primary)	-2.9%	[-3.3%, -2.4%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-3.3%, -2.4%]	2

Footnotes

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

2. number of relevant changes↩↩²↩³

[Kobzol]

The diesel-1.4.8 benchmark still seems to fail even with this PR.

[compiler-errors]

Ugh, seriously? I am just going to revert this is_impossible_method PR then until I can fix it correctly. 🤦

[Kobzol]

I'd be glad to be wrong, but the error is still there (this commit was already perf-tested) https://perf.rust-lang.org/status.html and when I tried 983f4daddf238d114c4adc4751c5528fc6695a5a locally with rustc-perf, it still failed.

[rylev]

Note: #100991 is tracking this and has some small additional context.

[compiler-errors]

The primary perf regression on this PR seems to be reversed by #101039, though given the nature of this PR being rustdoc specific, I wouldn't be surprised if it were just noise. Also that PR fixes the diesel doc issue.

[rylev]

Marking this as triaged given the analysis above.

@rustbot label: +perf-regression-triaged