`rustc_ast_pretty::pp` defines `Printer` and has a 346 line `impl
Printer` block for it. `rustc_ast_pretty::pp::convenience` has another
`impl Printer` block with 85 lines. `rustc_ast_pretty::helpers` has
another `impl Printer` block with 45 lines.
This commit merges the two small `impl Printer` blocks into the bigger
one, because there is no good reason for them to be separate. Doing this
eliminates the `rustc_ast_pretty::pp::convenience` and
`rustc_ast_pretty::helpers` modules; no great loss given that they were
small and had extremely generic names.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#154912 (Remove `BuiltinLintDiag`)
- rust-lang/rust#154598 (test `#[naked]` with `#[link_section = "..."]` on windows)
- rust-lang/rust#154719 (Hexagon inline asm: add reg_pair, vreg, vreg_pair, and qreg register classes)
- rust-lang/rust#154057 (Parenthesize block-like expressions in index base of pretty printer)
- rust-lang/rust#154893 (make `expected_literal` positive)
- rust-lang/rust#155002 (Clarify that `core::range` ranges do not have special syntax)
When a macro expands to a call whose callee is a block (or other
"complete" expression like `match`, `if`, `loop`), the AST pretty
printer emits the callee without parentheses. In statement position
the closing brace ends the expression and the argument list is parsed
as a separate tuple expression, producing a parse error.
The AST pretty printer produces invalid Rust when a block expression is
the base of an index operation inside a macro expansion. This is a gap
in the existing `FixupContext` parenthesization machinery — the approach
handles statement position but not the case where a block-index is
nested inside another expression.
The following is a correct program:
```rust
macro_rules! block_arr {
() => {{ [0u8; 4] }};
}
macro_rules! as_slice {
() => {{ &block_arr!()[..] }};
}
fn main() { let _: &[u8] = as_slice!(); }
```
But `rustc -Zunpretty=expanded` produces output that is not valid Rust,
because the closing brace of `{ [0u8; 4] }` creates a statement
boundary, causing the parser to treat `[..]` as a separate expression:
```rust
fn main() { let _: &[u8] = { &{ [0u8; 4] }[..] }; }
```
```
error: expected one of `.`, `;`, `?`, `}`, or an operator, found `[`
```
Fixed output after this change:
```rust
fn main() { let _: &[u8] = { &({ [0u8; 4] })[..] }; }
```
Since `{ ... }[...]` never parses as indexing a block regardless of
context, the fix unconditionally parenthesizes "complete" expressions
(block, match, if, loop, etc.) when they appear as the base of an index
operation.
Reorder inline asm operands in pretty printer to satisfy grammar constraints
After macro expansion, named `asm!` operands are converted to positional operands and the template string uses numeric indices. However, the pretty printer previously emitted operands in their original AST order, which could place positional (formerly named) register-class operands after explicit register operands. This violates the `asm!` grammar rule that positional arguments cannot follow explicit register arguments, causing the expanded output from `rustc -Zunpretty=expanded` to fail to reparse.
When reordering is needed, the fix partitions operands into non-explicit and explicit register groups, emits non-explicit operands first, then explicit register operands, and remaps template placeholder indices (`{N}`) to match the new positions. When operands are already correctly ordered, the original code path is used unchanged.
## Example
**before** (`rustc 1.96.0-nightly (3b1b0ef4d 2026-03-11)`):
```rust
#![feature(prelude_import)]
#![no_std]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
//@ pretty-mode:expanded
//@ pp-exact:asm-operand-order.pp
//@ only-x86_64
use std::arch::asm;
pub fn main() {
unsafe {
asm!("{1}", out("rax") _, in(reg) 4);
asm!("{1}", out("rax") _, in(reg) 4, options(nostack));
asm!("{1} {2}", out("rax") _, in(reg) 4, in(reg) 5);
}
}
```
**after** (this branch):
```rust
#![feature(prelude_import)]
#![no_std]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
//@ pretty-mode:expanded
//@ pp-exact:asm-operand-order.pp
//@ only-x86_64
use std::arch::asm;
pub fn main() {
unsafe {
asm!("{0}", in(reg) 4, out("rax") _);
asm!("{0}", in(reg) 4, out("rax") _, options(nostack));
asm!("{0} {1}", in(reg) 4, in(reg) 5, out("rax") _);
}
}
```
Notice the operand reordering: in the before, explicit register operands (`out("rax")`) appear before positional operands (`in(reg)`), violating the grammar (E0662). The template references are also wrong (`{1}` instead of `{0}`). The after moves positional operands first and renumbers the template references accordingly.
Add macro matcher for `guard` fragment specifier
Tracking issue #153104
This PR implements a new `guard` macro matcher to match `if-let` guards (specifically [`MatchArmGuard`](https://github.com/rust-lang/reference/blob/50a1075e879be75aeec436252c84eef0fad489f4/src/expressions/match-expr.md#match-guards)). In the upcoming PR, we can use this new matcher in the `matches!` and `assert_matches!` macros to support their use with `if-let` guards. (see #152313)
The original `Expr` used to represent a guard has been wrapped in a new `Guard` type, allowing us to carry the span information of the leading `if` keyword. However, it might be even better to include the `if` keyword in the `Guard` type as well? I've left a FIXME comment in the code.
Extract the inline asm operand reorder/remap logic into a dedicated helper so
`print_inline_asm` stays focused on assembling the printed argument list.
This keeps the reordered-template logic local to the AST pretty printer while
making the main printing path easier to read.
Also extend the pretty regression test with a `const` operand case. That checks
that non-register operands other than `in(reg)` are also moved ahead of explicit
register operands and that the remapped template indices still match the new
operand order.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
Fix whitespace after fragment specifiers in macro pretty printing
When a macro-generating-macro captures fragment specifier tokens (like `$x:ident`) as `tt` metavariables and replays them before a keyword (like `where`), the pretty printer concatenates them into an invalid fragment specifier (e.g. `$x:identwhere` instead of `$x:ident where`).
This happens because `tt` captures preserve the original token spacing. When the fragment specifier name (e.g. `ident`) was originally the last token before a closing delimiter, it retains `JointHidden` spacing. The `print_tts` function only checks `space_between` for `Spacing::Alone` tokens, so `JointHidden` tokens skip the space check entirely, causing adjacent identifier-like tokens to merge.
The fix adds a check in `print_tts` to insert a space between adjacent identifier-like tokens (identifiers and keywords) regardless of the original spacing, preventing them from being concatenated into invalid tokens.
This is similar to the existing `space_between` mechanism that prevents token merging for `Spacing::Alone` tokens, extended to also handle `Joint`/`JointHidden` cases where two identifier-like tokens would merge.
## Example
**before** (`rustc 1.96.0-nightly (3b1b0ef4d 2026-03-11)`):
```rust
#![feature(prelude_import)]
#![no_std]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
//@ pretty-mode:expanded
//@ pp-exact:macro-fragment-specifier-whitespace.pp
// Test that fragment specifier names in macro definitions are properly
// separated from the following keyword/identifier token when pretty-printed.
// This is a regression test for a bug where `$x:ident` followed by `where`
// was pretty-printed as `$x:identwhere` (an invalid fragment specifier).
macro_rules! outer {
($d:tt $($params:tt)*) =>
{
#[macro_export] macro_rules! inner
{ ($($params)* where $d($rest:tt)*) => {}; }
};
}
#[macro_export]
macro_rules! inner { ($x:identwhere $ ($rest : tt)*) => {}; }
fn main() {}
```
**after** (this branch):
```rust
#![feature(prelude_import)]
#![no_std]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
//@ pretty-mode:expanded
//@ pp-exact:macro-fragment-specifier-whitespace.pp
// Test that fragment specifier names in macro definitions are properly
// separated from the following keyword/identifier token when pretty-printed.
// This is a regression test for a bug where `$x:ident` followed by `where`
// was pretty-printed as `$x:identwhere` (an invalid fragment specifier).
macro_rules! outer {
($d:tt $($params:tt)*) =>
{
#[macro_export] macro_rules! inner
{ ($($params)* where $d($rest:tt)*) => {}; }
};
}
#[macro_export]
macro_rules! inner { ($x:ident where $ ($rest : tt)*) => {}; }
fn main() {}
```
Notice the `$x:identwhere` in the before — an invalid fragment specifier that causes a hard parse error. The after correctly separates it as `$x:ident where`.
Insert space after float literal ending with `.` in pretty printer
The pretty printer was collapsing unsuffixed float literals (like `0.`) with adjacent dot tokens, producing ambiguous or invalid output:
- `0. ..45.` (range) became `0...45.`
- `0. ..=360.` (inclusive range) became `0...=360.`
- `0. .to_string()` (method call) became `0..to_string()`
The fix inserts a space after an unsuffixed float literal ending with `.` when it appears as the start expression of a range operator or the receiver of a method call or field access, preventing the trailing dot from merging with the following `.`, `..`, or `..=` token. This is skipped when the expression is already parenthesized, since the closing `)` naturally provides separation.
## Example
**before** (`rustc 1.96.0-nightly (3b1b0ef4d 2026-03-11)`):
```rust
#![feature(prelude_import)]
#![no_std]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
//@ pp-exact
fn main() {
let _ = 0...45.;
let _ = 0...=360.;
let _ = 0...;
let _ = 0..to_string();
}
```
**after** (this branch):
```rust
#![feature(prelude_import)]
#![no_std]
extern crate std;
#[prelude_import]
use ::std::prelude::rust_2015::*;
//@ pp-exact
fn main() {
let _ = 0. ..45.;
let _ = 0. ..=360.;
let _ = 0. ..;
let _ = 0. .to_string();
}
```
Notice `0...45.` (ambiguous — looks like deprecated `...` inclusive range) becomes `0. ..45.` (clear: float `0.` followed by range `..`). Similarly `0..to_string()` (parsed as range) becomes `0. .to_string()` (method call on float).
Preserve braces around `self` in use tree pretty printing
The AST pretty printer strips braces from single-item `use` sub-groups, simplifying `use foo::{Bar}` to `use foo::Bar`. However, when the single item is `self`, this produces `use foo::self` which is not valid Rust (E0429) — the grammar requires `use foo::{self}`.
This affects both `stringify!` and `rustc -Zunpretty=expanded`, causing `cargo expand` output to be unparseable when a crate uses `use path::{self}` imports (a common pattern in the ecosystem).
The fix checks whether the single nested item's path starts with `self` before stripping braces. If so, the braces are preserved.
## Example
**before** (`rustc 1.96.0-nightly (3b1b0ef4d 2026-03-11)`):
```rust
#![feature(prelude_import)]
//@ pp-exact
//@ edition:2021
#![allow(unused_imports)]
extern crate std;
#[prelude_import]
use std::prelude::rust_2021::*;
// Braces around `self` must be preserved, because `use foo::self` is not valid Rust.
use std::io::self;
use std::fmt::{self, Debug};
fn main() {}
```
**after** (this branch):
```rust
#![feature(prelude_import)]
//@ pp-exact
//@ edition:2021
#![allow(unused_imports)]
extern crate std;
#[prelude_import]
use std::prelude::rust_2021::*;
// Braces around `self` must be preserved, because `use foo::self` is not valid Rust.
use std::io::{self};
use std::fmt::{self, Debug};
fn main() {}
```
Notice the `use std::io::self` (invalid, E0429) in the before becomes `use std::io::{self}` in the after.
Add hygiene annotations for tokens in `macro_rules!` bodies
`-Zunpretty=expanded,hygiene` was not printing syntax context annotations for identifiers and lifetimes inside `macro_rules!` bodies. These tokens are printed via `print_tt()` → `token_to_string_ext()`, which converts tokens to strings without calling `ann_post()`. This meant that macro-generated `macro_rules!` definitions with hygienic metavar parameters (e.g. multiple `$marg` distinguished only by hygiene) were printed with no way to tell them apart.
This was fixed by adding a match on `token.kind` in `print_tt()` to call `ann_post()` for `Ident`, `NtIdent`, `Lifetime`, and `NtLifetime` tokens, matching how `print_ident()` and `print_lifetime()` already handle AST-level identifiers and lifetimes.
After macro expansion, named `asm!` operands are converted to positional
operands and the template string uses numeric indices. However, the pretty
printer previously emitted operands in their original AST order, which could
place positional (formerly named) register-class operands after explicit
register operands. This violates the `asm!` grammar rule that positional
arguments cannot follow explicit register arguments, causing the expanded
output from `rustc -Zunpretty=expanded` to fail to reparse.
When reordering is needed, the fix partitions operands into non-explicit and
explicit register groups, emits non-explicit operands first, then explicit
register operands, and remaps template placeholder indices (`{N}`) to match
the new positions. When operands are already correctly ordered, the original
code path is used unchanged.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
The pretty printer was collapsing unsuffixed float literals (like `0.`)
with adjacent dot tokens, producing ambiguous or invalid output:
- `0. ..45.` (range) became `0...45.`
- `0. ..=360.` (inclusive range) became `0...=360.`
- `0. .to_string()` (method call) became `0..to_string()`
The fix inserts a space after an unsuffixed float literal ending with
`.` when it appears as the start expression of a range operator or the
receiver of a method call or field access, preventing the trailing dot
from merging with the following `.`, `..`, or `..=` token. This is
skipped when the expression is already parenthesized, since the closing
`)` naturally provides separation.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
When a macro-generating-macro captures fragment specifier tokens (like
`$x:ident`) as `tt` metavariables and replays them before a keyword
(like `where`), the pretty printer concatenates them into an invalid
fragment specifier (e.g. `$x:identwhere` instead of `$x:ident where`).
This happens because `tt` captures preserve the original token spacing.
When the fragment specifier name (e.g. `ident`) was originally the last
token before a closing delimiter, it retains `JointHidden` spacing. The
`print_tts` function only checks `space_between` for `Spacing::Alone`
tokens, so `JointHidden` tokens skip the space check entirely, causing
adjacent identifier-like tokens to merge.
The fix adds a check in `print_tts` to insert a space between adjacent
identifier-like tokens (identifiers and keywords) regardless of the
original spacing, preventing them from being concatenated into invalid
tokens.
This is similar to the existing `space_between` mechanism that prevents
token merging for `Spacing::Alone` tokens, extended to also handle
`Joint`/`JointHidden` cases where two identifier-like tokens would merge.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
The AST pretty printer was dropping parentheses around or-patterns
when they appeared inside `@` bindings, `&` references, or `box`
patterns. For example:
- `v @ (1 | 2 | 3)` was printed as `v @ 1 | 2 | 3`
- `&(1 | 2 | 3)` was printed as `&1 | 2 | 3`
- `box (1 | 2 | 3)` was printed as `box 1 | 2 | 3`
Since `|` has the lowest precedence among pattern operators, all of
these are parsed incorrectly without parentheses — e.g. `v @ 1 | 2 | 3`
becomes `(v @ 1) | 2 | 3`, binding `v` only to the first alternative.
This caused E0408 ("variable not bound in all patterns") when the
expanded output was fed back to the compiler, affecting crates like
html5ever and wgpu-core that use macros expanding to or-patterns
after `@`.
The fix adds a `print_pat_paren_if_or` helper that wraps `PatKind::Or`
subpatterns in parentheses, and uses it in the `@`, `&`, and `box`
printing arms. This is similar in spirit to the existing `FixupContext`
parenthesization approach used for expression printing.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
The AST pretty printer strips braces from single-item `use` sub-groups,
simplifying `use foo::{Bar}` to `use foo::Bar`. However, when the single
item is `self`, this produces `use foo::self` which is not valid Rust
(E0429) — the grammar requires `use foo::{self}`.
This affects both `stringify!` and `rustc -Zunpretty=expanded`, causing
`cargo expand` output to be unparseable when a crate uses `use
path::{self}` imports (a common pattern in the ecosystem).
The fix checks whether the single nested item's path starts with `self`
before stripping braces. If so, the braces are preserved.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
It's defined in `rustc_span::source_map` which doesn't make any sense
because it has nothing to do with source maps. This commit moves it to
the crate root, a more sensible spot for something this basic.
The AST pretty printer was dropping parentheses around `Fn` trait
bounds in `dyn`/`impl` types when additional `+` bounds were present.
For example:
dyn (FnMut(&mut T) -> &mut dyn ResourceLimiter) + Send + Sync
was pretty-printed as:
dyn FnMut(&mut T) -> &mut dyn ResourceLimiter + Send + Sync
Without parens, `+ Send + Sync` binds to the inner `dyn ResourceLimiter`
instead of the outer type, producing invalid Rust.
The parser already tracks parentheses via `PolyTraitRef.parens`, but
`print_poly_trait_ref` never checked this field. This adds `popen()`
and `pclose()` calls when `parens == Parens::Yes`.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
Parse `impl` restrictions
This PR implements the parsing logic for `impl` restrictions (e.g., `pub impl(crate) trait Foo {}`) as proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html).
As the first step of the RFC implementation, this PR focuses strictly on the parsing phase. The new syntax is guarded by the `#![feature(impl_restriction)]` feature gate.
This implementation basically follows the pattern used in rust-lang/rust#141754.
r? @jhpratt
Don’t report missing fields in struct exprs with syntax errors.
@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.
Specifically, if the user writes a struct literal with a syntax error, such as
```rust
StructName { foo: 1 bar: 2 }
```
the compiler will no longer report that the field `bar` is missing in addition to the syntax error.
This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.
**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.
`-Zunpretty=expanded,hygiene` was not printing syntax context annotations
for identifiers and lifetimes inside `macro_rules!` bodies. These tokens
are printed via `print_tt()` → `token_to_string_ext()`, which converts
tokens to strings without calling `ann_post()`. This meant that
macro-generated `macro_rules!` definitions with hygienic metavar
parameters (e.g. multiple `$marg` distinguished only by hygiene) were
printed with no way to tell them apart.
This was fixed by adding a match on `token.kind` in `print_tt()` to call
`ann_post()` for `Ident`, `NtIdent`, `Lifetime`, and `NtLifetime`
tokens, matching how `print_ident()` and `print_lifetime()` already
handle AST-level identifiers and lifetimes.
Signed-off-by: Andrew V. Teylu <andrew.teylu@vector.com>
This adds a variant `NoneWithError` to AST and HIR representations of
the “rest” or “tail”, which is currently always treated identically to
the `None` variant.
Revert, but without type const.
Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.
Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.
Fix for tidyfmt and some errors when manually resolving a merge conflicts.
Update these tests to use update error messages and type const syntax.
Update comments and error message to use new syntax instead of old type_const attribute.
Remove the type_const attribute
update some more tests to use the new syntax.
Update these test cases.
update feature gate test
Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.
Create a new feature gate that checks for the feature before expansion.
Make rustfmt handle the `type const` syntax correctly.
Add a convience method to check if a RhsKind is type const.
Rename `Const` discriminant to `Body` for `ConstItemRhsKind`
Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.
Update formatting for these match statements.
Update clippy test to use type const syntax.
Update test to use type const syntax.
update rustfmt to match ast items.
Update clippy to match ast and hir items.
Few more test cases that used old attribute, instead of 'type const'
Update to match the output from the feature gate checks.
tidyfmt adjustments.
Update the is_type_const, so I can constrain record!(..) in encoder.rs
Update conditional compilation test.
Move the feature gate to after expansion to allow for cfg(...) to work.
Update some more tests to use the new syntax.
Update type const tests in associated-const-bindings to use new syntax.
Don't check based off the attribute, but the item here.
Update some tests outside of the const_generics folder that were using #[type_const]
update the tests in associated consts that use #[type_const] to use type const
Update these mgca tests with the type const syntax.
Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.
Don't need into for these now that it's a query.
Add is_type_const query to handle foreign def ids.
update this test to use type const syntax.
Fix logic here, we only want to lower if there is expression in this case.
Update built-in macros to use ConstItemRhsKind
Update more instance of the old ConstItemRhs.
Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.
Update lower to use ConstItemKind
Add an other helper method to check if the rhs kinda has an expr.
Update item parse to use ConstItemKind enum.
Felt the field name could a be little clear when editing a few other things.
Change the ConstItem struct see know if we have a type const or regular const.
Make sure this syntax is properly feature gated.
`-Zunpretty=expanded,hygiene` was not printing the syntax context for
lifetimes. For example, two macro-generated lifetimes `'a` with different
hygiene would both print as `/* 2538 */` instead of `/* 2538#0 */` and
`/* 2538#1 */`, making it impossible to distinguish them.
This was fixed by changing `print_lifetime` to call `ann_post()` with
the full `Ident`, matching how regular identifiers are handled in
`print_ident`.
Port `doc` attributes to new attribute API
Part of https://github.com/rust-lang/rust/issues/131229.
This PR ports the `doc` attributes to the new attribute API. However, there are things that will need to be fixed in a follow-up:
* Some part of `cfg_old.rs` are likely unused now, so they should be removed.
* Not all error/lints are emitted at the same time anymore, making them kinda less useful considering that you need to run and fix rustc/rustdoc multiple times to get through all of them.
* For coherency with the other attribute errors, I didn't modify the default output too much, meaning that we have some new messages now. I'll likely come back to that to check if the previous ones were better in a case-by-case approach.
* `doc(test(attr(...)))` is handled in a horrifying manner currently. Until we can handle it correctly with the `Attribute` system, it'll remain that thing we're all very ashamed of. 😈
* A type in rustdoc got its size increased, I'll check the impact on performance. But in any case, I plan to improve it in a follow-up so should be "ok".
* Because of error reporting, some fields of `Doc` are suboptimal, like `inline` which instead of being an `Option` is a `ThinVec` because we report the error later on. Part of the things I'm not super happy about but can be postponed to future me.
* In `src/librustdoc/clean/cfg.rs`, the `pub(crate) fn parse(cfg: &MetaItemInner) -> Result<Cfg, InvalidCfgError> {` function should be removed once `cfg_trace` has been ported to new `cfg` API.
* Size of type `DocFragment` went from 32 to 48. Would be nice to get it back to 32.
* ``malformed `doc` attribute input`` wasn't meant for so many candidates, should be improved.
* See how many of the checks in `check_attr` we can move to attribute parsing
* Port target checking to be in the attribute parser completely
* Fix target checking for `doc(alias)` on fields & patterns
And finally, once this PR is merged, I plan to finally stabilize `doc_cfg` feature. :)
cc `@jdonszelmann`
r? `@JonathanBrouwer`
148725 moved the default to being homogeneous; this adds heterogeneous ones back under an obvious-bikeshed syntax so people can experiment with that as well.
Essentially resolves 149025 by letting them move to this syntax instead.
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
CoCo-Japan-pan