lazily reveal opaque types during ctfe in typeck

[lcnr]

implements the idea mentioned in #101478 (comment)

r? @oli-obk

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 9f0147b3322caa1458d1b18d3131565dc8cb4e56 with merge 4f82b8341b3d3e2d0102a70d4c76a13fa7570528...

[bors]

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

[rust-timer]

Queued 4f82b8341b3d3e2d0102a70d4c76a13fa7570528 with parent ead49f0, future comparison URL.

[rust-timer]

Finished benchmarking commit (4f82b8341b3d3e2d0102a70d4c76a13fa7570528): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

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

Warning ⚠: The following benchmark(s) failed to build:

• deeply-nested-multi

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.4%	[0.2%, 0.8%]	5
Regressions ❌ (secondary)	3.7%	[0.7%, 9.0%]	11
Improvements ✅ (primary)	-0.4%	[-0.6%, -0.2%]	16
Improvements ✅ (secondary)	-0.6%	[-1.1%, -0.4%]	5
All ❌✅ (primary)	-0.2%	[-0.6%, 0.8%]	21

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.4%	[0.4%, 0.4%]	1
Regressions ❌ (secondary)	3.0%	[1.7%, 4.7%]	3
Improvements ✅ (primary)	-2.9%	[-2.9%, -2.9%]	1
Improvements ✅ (secondary)	-2.0%	[-3.0%, -1.0%]	4
All ❌✅ (primary)	-1.2%	[-2.9%, 0.4%]	2

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)	4.0%	[2.1%, 9.7%]	11
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Footnotes

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

2. number of relevant changes ↩ ↩² ↩³

[bors]

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

[lcnr]

closing as the maintenance cost of this approach feels too high. Laid out my reasoning in https://hackmd.io/@lcnr/BkNePDPlo and intend to open a pr in the near future adding tests and removing some of the reveal_all_normalized calls.