Encode MIR for const ctors in metadata and allow eval for them

[camelid]

Fixes #132985.

This is needed for them to be usable under min_generic_const_args (mgca).

Whenever a const ctor appears as an expression, like in let x = Foo;,
it is directly lowered to a construction of an aggregate value in MIR,
instead of using the const generated for it. The anon const approach for
generic const exprs works similarly, by creating an anon const with the
aggregate as its body. However, with mgca, we want to avoid anon consts,
so we need to use the const item. They were not previously encoded in
the metadata MIR, so they could not be used cross-crate, and they were
not able to be evaluated. This change fixes that.

r? @BoxyUwU

[camelid]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 55cc8e4 with merge e10a2b0...

[camelid]

See previous discussion here: #131081 (comment). It seems like the only concerns were perf (which is currently being run on this PR), and also making sure it made sense to wg-const-eval?

[camelid]

cc @fee1-dead

[compiler-errors]

They are not currently encoded for some reason.

They are not encoded because they are currently lowered in expression position (i.e. from hir::ExprKind::Path whose Res is a CtorKind::Const) during MIR building to Rvalue::Aggregate rather than being represented as Rvalue::Const which point to a const body (the body, specifically, that we'd be encoding now). So they're never needed currently in MIR.

Since AFAICT we want to represent consts in min_generic_const_args uniformly as ConstKind::Unevaluated that points directly to the constructor's const (rather than, in GCE, an anon const whose body contains a single expression which would be that Rvalue::Aggregate according to the lowering mentioned above), we now need to encode these so that we can evalaute the consts correctly cross-crate.

I think this approach makes sense and if this isn't too expensive, we'd probably be best off doing this rather than -- for example -- introducing a new hack to make up for that missing MIR body when we pass a struct literal in a generic arg.

[bors]

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

[camelid]

They are not currently encoded for some reason.

They are not encoded because they are currently lowered in expression position (i.e. from hir::ExprKind::Path whose Res is a CtorKind::Const) during MIR building to Rvalue::Aggregate rather than being represented as Rvalue::Const which point to a const body (the body, specifically, that we'd be encoding now). So they're never needed currently in MIR.

Since AFAICT we want to represent consts in min_generic_const_args uniformly as ConstKind::Unevaluated that points directly to the constructor's const (rather than, in GCE, an anon const whose body contains a single expression which would be that Rvalue::Aggregate according to the lowering mentioned above), we now need to encode these so that we can evalaute the consts correctly cross-crate.

I think this approach makes sense and if this isn't too expensive, we'd probably be best off doing this rather than -- for example -- introducing a new hack to make up for that missing MIR body when we pass a struct literal in a generic arg.

Right, this is consistent with what I understand too. I'm not sure why I said "for some reason" -- I'll fix the commit message/PR description before merging.

EDIT: Fixed. Also feel free to edit yourself if anything's unclear. :)

[rust-log-analyzer]

The job x86_64-gnu-llvm-18 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#21 exporting to docker image format
#21 sending tarball 28.4s done
#21 DONE 41.3s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-18]
debug: `DISABLE_CI_RUSTC_IF_INCOMPATIBLE` configured.
---
sccache: Starting the server...
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-18', '--enable-llvm-link-shared', '--set', 'rust.randomize-layout=true', '--set', 'rust.thin-lto-import-instr-limit=10', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--enable-new-symbol-mangling']
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-18/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.randomize-layout := True
configure: rust.thin-lto-import-instr-limit := 10

[rust-timer]

Finished benchmarking commit (e10a2b0): comparison URL.

Overall result: ❌ regressions - please read the text below

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 the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 0.7%]	31
Regressions ❌ (secondary)	8.2%	[0.3%, 24.8%]	16
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.2%, 0.7%]	31

Max RSS (memory usage)

Results (primary 0.4%, secondary 7.9%)

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.8%	[0.5%, 1.2%]	4
Regressions ❌ (secondary)	7.9%	[0.9%, 21.3%]	12
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[-1.2%, 1.2%]	5

Cycles

Results (primary 0.6%, secondary 15.8%)

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.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	15.8%	[2.5%, 28.5%]	11
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.6%	[0.6%, 0.6%]	1

Binary size

Results (primary 0.3%, secondary 7.7%)

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.1%]	101
Regressions ❌ (secondary)	7.7%	[0.1%, 27.9%]	26
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.0%, 1.1%]	101

Bootstrap: 763.48s -> 762.494s (-0.13%)
Artifact size: 325.50 MiB -> 325.41 MiB (-0.03%)