Fix bad span of well-formed evaluation overflow

[Kokoro2336]

Fixes #157619

Refine bad span of well-formed evaluation overflow

[rustbot]

changes to the core type system

cc @lcnr

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 21 candidates

[Kokoro2336]

The original issue also requires more detailed indication on the problematic type. But since the evaluation is cyclic and the real type is never inferred, it would be tricky to print the concrete type in the message, so I didn't impl it in the PR.

[lcnr]

@bors try @rust-timer queue

[lcnr]

r? lcnr

[rust-bors]

☀️ Try build successful (CI)
Build commit: b972397 (b9723978c3d9915ba1b031bc5b40125c7a4a20d3)
Base parent: 5503df8 (5503df87342a73d0c29126a7e08dc9c1255c46ad)

[rust-timer]

Finished benchmarking commit (b972397): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.2%, 0.3%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -2.2%, secondary -1.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.0%	[0.8%, 1.1%]	2
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-4.2%	[-4.4%, -3.9%]	2
All ❌✅ (primary)	-2.2%	[-2.2%, -2.2%]	1

Cycles

Results (secondary 4.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.3%	[2.7%, 6.4%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 487.42s -> 491.122s (0.76%)
Artifact size: 389.91 MiB -> 389.77 MiB (-0.04%)

[rust-bors]

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

[lcnr]

sorry for the late review. My vibe is that this change feels somewhat too targeted and I dislike tracking additional information in the type variable storage without that being "core" to the type system. It makes it harder to reason about things and I generally feel somewhat worried about the perf impact/complexity of doing this.

I think as a more general things the well-formedness goal is not what "causes" overflows here. We should have some Subtype obligations which cause the fulfillment context to overflow instead. And these should already have the correct spans 🤔

Can you look into whether there's also a fulfillment error for a subtype obligation we could point to instead

View changes since this review