MGCA: Syntactically distinguish anon const const args

[BoxyUwU]

r? oli-obk

tracking issue: #132980

This PR requires that when feature(min_generic_const_args) is enabled, anon const const args are syntactically distinguishable from other kinds of args. We use const { ... } in const argument position to denote an anon const:

#![feature(min_generic_const_args)]

// no longer allowed as `1 + 1` is represented via an anon const and
// there is no syntactic marker
type Foo = [(); 1 + 1];

// allowed, `const { ... }` indicates an anon const representation
type Foo = [(); const { 1 + 1 }];

This restriction is only placed when mgca is enabled. There should be no effect on stable. This restriction is not enforced for unbraced literals which we continue to implicitly wrap in an anon const: tests/ui/const-generics/mgca/explicit_anon_consts_literals_hack.rs

This restriction allows us to create DefIds for anon consts only when actually required. When it is syntactically ambiguous whether a const argument is an anon const or not we are forced to conservatively create a DefId for every const argument even if it doesn't wind up needing one.

This works fine on stable but under mgca we can wind up with anon consts nested inside non-anon-const const arguments resulting in a broken DefId tree. See #148838 where an anon const arg inside of a path arg winds up with a parent of a conservatively created DefId that doesn't actually correspond to an anon const, resulting in an ICE.

With #149114 every field initialiser in a const argument would become a place where there could possibly be an anon const. This would also get worse once we support tuple constructors- now every function argument is a place where there could possibly be an anon const.

We introduce this restriction to avoid creating massive amounts of unused DefIds that make the parent tree significantly more complicated, and to avoid having to paper over this issue in things like generics_of.

Fixes #148838

It also must be syntactically clear from context whether '_ means an inference lifetime or an elided lifetime parameter. This restriction will allow us to properly resolve '_ in const arguments in mgca. This PR doesn't actually fix handle this, but we could do so trivially after this lands.

[rustbot]

Some changes occurred in compiler/rustc_builtin_macros/src/autodiff.rs

cc @ZuseZ4

[rustbot]

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[bors]

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

[oli-obk]

r=me with commits cleaned up

[BoxyUwU]

@bors r=oli-obk rollup=never

[bors]

📌 Commit 0c86a41 has been approved by oli-obk

It is now in the queue for this repository.

[BoxyUwU]

@bors r=oli-obk

[bors]

💡 This pull request was already approved, no need to approve it again.

• This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.
• There's another pull request that is currently being tested, blocking this pull request: bump bootstrap compiler to 1.93 beta #149831

[bors]

📌 Commit 0c86a41 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

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

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[BoxyUwU]

@bors r=oli-obk

[bors]

📌 Commit acc3a0e has been approved by oli-obk

It is now in the queue for this repository.

[BoxyUwU]

@bors r-

actually should wait for CI to pass given rebase

[BoxyUwU]

@bors r=oli-obk

[bors]

📌 Commit acc3a0e has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit acc3a0e with merge dc47a69...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing dc47a69 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing fa5eda1 (parent) -> dc47a69 (this PR)

Test differences

Show 56 test diffs

Stage 1

• [ui] tests/ui/associated-type-bounds/const-projection-err.rs: [missing] -> pass (J1)
• [ui] tests/ui/associated-type-bounds/const-projection-err.rs#gce: pass -> [missing] (J1)
• [ui] tests/ui/associated-type-bounds/const-projection-err.rs#stock: pass -> [missing] (J1)
• [ui] tests/ui/const-generics/mgca/explicit_anon_consts.rs: [missing] -> pass (J1)
• [ui] tests/ui/const-generics/mgca/explicit_anon_consts_literals_hack.rs: [missing] -> pass (J1)
• [ui] tests/ui/const-generics/mgca/multi_braced_direct_const_args.rs: [missing] -> pass (J1)
• [ui] tests/ui/const-generics/mgca/unbraced_const_block_const_arg_gated.rs: [missing] -> pass (J1)

Stage 2

• [ui] tests/ui/associated-type-bounds/const-projection-err.rs: [missing] -> pass (J0)
• [ui] tests/ui/associated-type-bounds/const-projection-err.rs#gce: pass -> [missing] (J0)
• [ui] tests/ui/associated-type-bounds/const-projection-err.rs#stock: pass -> [missing] (J0)
• [ui] tests/ui/const-generics/mgca/explicit_anon_consts.rs: [missing] -> pass (J0)
• [ui] tests/ui/const-generics/mgca/explicit_anon_consts_literals_hack.rs: [missing] -> pass (J0)
• [ui] tests/ui/const-generics/mgca/multi_braced_direct_const_args.rs: [missing] -> pass (J0)
• [ui] tests/ui/const-generics/mgca/unbraced_const_block_const_arg_gated.rs: [missing] -> pass (J0)

Additionally, 42 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-20-1, aarch64-msvc-1, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-gnu, x86_64-gnu-debug, x86_64-gnu-gcc, x86_64-gnu-llvm-20, x86_64-gnu-llvm-20-2, x86_64-gnu-llvm-21-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
• J1: x86_64-gnu-llvm-20-3, x86_64-gnu-llvm-21-3

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard dc47a69ed94bc88b10b7d500cceacf29b87bcbbe --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-gnu-llvm-21-1: 3238.0s -> 3753.9s (+15.9%)
2. aarch64-gnu-llvm-20-2: 2251.0s -> 2580.7s (+14.6%)
3. aarch64-gnu-llvm-20-1: 3378.5s -> 3871.9s (+14.6%)
4. pr-check-1: 1704.8s -> 1944.8s (+14.1%)
5. x86_64-gnu-gcc: 3135.0s -> 3539.2s (+12.9%)
6. dist-x86_64-apple: 7034.7s -> 7918.2s (+12.6%)
7. test-various: 6532.0s -> 7318.2s (+12.0%)
8. x86_64-rust-for-linux: 2870.8s -> 3208.8s (+11.8%)
9. dist-apple-various: 4078.6s -> 3617.3s (-11.3%)
10. dist-aarch64-llvm-mingw: 6546.5s -> 5988.1s (-8.5%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (dc47a69): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (secondary 0.8%)

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)	0.8%	[0.8%, 0.9%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -4.0%)

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

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 473.976s -> 475.622s (0.35%)
Artifact size: 389.30 MiB -> 389.31 MiB (0.00%)