Create definitions for promoted constants.

[cjgillot]

The current handling of promoted carries an Option<Promoted> everywhere to disambiguate the normal item from the constant.

This PR replaces the promoted constants by new definitions with new DefKind::Promoted.
This method allows to unify borrow-checking with the code path for inline consts.

The main caveat is creating even more definitions that do not have any HIR associated, triggering new corner cases where local_def_id_to_hir_id panics.

[rustbot]

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

[bors]

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

[Nilstrieb]

Does it make sense to remove local_def_id_to_hir_id and only keep the fallible variant afterwards? Having these panicking functions seems like a footguns.

[cjgillot]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ece7178 with merge 9544b34e922aa47c0406b4eeb76fe0937973d406...

[cjgillot]

We stop borrow-checking promoted as part of the enclosing body, so they keep being checked only once. They now work exactly like inline consts.

However, we now run the rest of borrow-checking on them, and pay the extra cost of setting-up and cleaning-up the borrow-checking environment: renumbering regions, solving them, and wrapping that up into a nice BorrowCheckResult.

Profiling that led me to #111753 and #111759. This PR's perf will have to be re-checked on those land.

[cjgillot]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 6ace5ea with merge 42412266728f075fe25b6499de0e33bc656748b9...

[bors]

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

[rust-timer]

Finished benchmarking commit (42412266728f075fe25b6499de0e33bc656748b9): 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-perf +perf-regression

Instruction count

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

	mean	range	count
Regressions ❌ (primary)	18.3%	[0.3%, 88.3%]	160
Regressions ❌ (secondary)	13.9%	[0.2%, 78.8%]	39
Improvements ✅ (primary)	-0.9%	[-1.0%, -0.7%]	2
Improvements ✅ (secondary)	-1.0%	[-1.1%, -1.0%]	2
All ❌✅ (primary)	18.1%	[-1.0%, 88.3%]	162

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.

	mean	range	count
Regressions ❌ (primary)	9.2%	[1.3%, 35.3%]	106
Regressions ❌ (secondary)	16.7%	[1.1%, 61.3%]	19
Improvements ✅ (primary)	-1.1%	[-1.7%, -0.5%]	2
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	9.0%	[-1.7%, 35.3%]	108

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.

	mean	range	count
Regressions ❌ (primary)	25.1%	[1.1%, 90.4%]	123
Regressions ❌ (secondary)	33.4%	[3.1%, 88.6%]	18
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	25.1%	[1.1%, 90.4%]	123

Binary size

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.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.0%, 1.8%]	73
Regressions ❌ (secondary)	0.2%	[0.0%, 0.5%]	18
Improvements ✅ (primary)	-0.7%	[-1.4%, -0.2%]	32
Improvements ✅ (secondary)	-1.0%	[-2.4%, -0.0%]	46
All ❌✅ (primary)	-0.0%	[-1.4%, 1.8%]	105

Bootstrap: 643.295s -> 644.706s (0.22%)

[cjgillot]

@bors try @rust-timer queue

[bors]

⌛ Trying commit d07bb8e with merge c8983833ea528097b0bfc7fb2b3b267dc37abfa3...

[bors]

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

[rust-timer]

Finished benchmarking commit (c8983833ea528097b0bfc7fb2b3b267dc37abfa3): 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-perf +perf-regression

Instruction count

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

	mean	range	count
Regressions ❌ (primary)	7.7%	[0.3%, 49.5%]	161
Regressions ❌ (secondary)	5.7%	[0.2%, 70.1%]	67
Improvements ✅ (primary)	-1.0%	[-1.0%, -1.0%]	1
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	4
All ❌✅ (primary)	7.7%	[-1.0%, 49.5%]	162

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.

	mean	range	count
Regressions ❌ (primary)	6.0%	[1.4%, 17.9%]	87
Regressions ❌ (secondary)	16.6%	[2.2%, 60.7%]	16
Improvements ✅ (primary)	-0.5%	[-0.5%, -0.5%]	1
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	5.9%	[-0.5%, 17.9%]	88

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.

	mean	range	count
Regressions ❌ (primary)	9.7%	[1.1%, 51.0%]	124
Regressions ❌ (secondary)	18.9%	[1.9%, 80.0%]	19
Improvements ✅ (primary)	-8.8%	[-16.5%, -4.3%]	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	8.7%	[-16.5%, 51.0%]	131

Binary size

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.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.0%, 1.9%]	74
Regressions ❌ (secondary)	0.2%	[0.0%, 0.5%]	18
Improvements ✅ (primary)	-0.7%	[-1.4%, -0.2%]	32
Improvements ✅ (secondary)	-1.0%	[-2.4%, -0.0%]	46
All ❌✅ (primary)	-0.0%	[-1.4%, 1.9%]	106

Bootstrap: 641.899s -> 645.473s (0.56%)

[cjgillot]

The performance degradation in incremental is due to a current limitation of creating new definitions. When we create a new definition, we make the creator query depend on the forever-red dep-node. This means that in the incremental scenario, we force mir_promoted to be recomputed if it ever promotes anything, and recursively this requires building MIR and THIR.

There is also a perf degradation in non-incremental, inside borrowck. I haven't found its cause yet.

[Dylan-DPC]

Closing this as it was an experiment and has too many conflicts

[oli-obk]

Since I forgot to cross link it: I'm working on fixing the perf issues here via #115613