MGCA: Syntactically distinguish anon const const args
r? oli-obk
tracking issue: rust-lang/rust#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:
```rust
#![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 `DefId`s 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 rust-lang/rust#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 rust-lang/rust#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 `DefId`s that make the parent tree significantly more complicated, and to avoid having to paper over this issue in things like `generics_of`.
Fixesrust-lang/rust#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.
dc47a69ed9