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 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.

[BoxyUwU]

I think that this very basic recursive setup means that under mgca we'd now accept {{ N }} and {{{{{{ <T as Trait>::ASSOC }}}}}} and whatnot. ie arbitrary braces surrounding direct args. this seems fine:tm: to me for now

[BoxyUwU]

tests/ui/const-generics/mgca/multi_braced_direct_const_args.rs

[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.