allow mGCA const arguments to fall back to anon consts by khyperia · Pull Request #158617 · rust-lang/rust

khyperia · 2026-06-30T14:41:17Z

makes good progress on rust-lang/project-const-generics#108

min_generic_const_args (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?"

Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context)

on stable, the full list of things can be directly represented is (... it's just the one thing)

paths to generic const parameters

on main, under mGCA, before this PR:

absolutely everything, if something cannot be represented directly, compiler error
const { } gives you an escape hatch to go back to being an anon const

on macroful gca, the directly represented things will be:

paths to const parameters
direct_const_arg! macro

on macroless gca, the directly represented things will be:

paths to const parameters
direct_const_arg! macro (not particularly useful under macroless gca)
struct expressions, arrays, blah blah
currently, paths to anything, even if that produces a compiler error later down the line (potential followup work here...)

this PR implements macroless gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning #[feature(min_generic_const_args)] to be macroful gca

Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above).

r? @BoxyUwU

rustbot · 2026-06-30T14:41:21Z

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

rustfmt is developed in its own repository. If possible, consider making this change to rust-lang/rustfmt instead.

cc @rust-lang/rustfmt

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

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

cc @ZuseZ4

rustbot · 2026-06-30T14:41:27Z

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

ytmimi

Would be great to also add a simple rustfmt test case annotated with #![feature(min_generic_const_args)] so we know it's for an unstable feature.

View changes since this review

ytmimi · 2026-06-30T23:10:07Z

+            ast::TyKind::DirectConstArg(ref expr) => {
+                let expr = expr.rewrite_result(context, shape)?;
+                Ok(format!("core::direct_const_arg!({expr})"))
+            }


Just double checking that core::direct_const_arg! won't show up as a macro call in the AST. Might be better to just return Err(RewriteError::Unknown) or even Ok(context.snippet(self.span).to_owned()) to return the span unchanged.

ah, good point, I didn't quite realize how rustfmt works, thank you! could you please double-check what I just force-pushed to make sure it's what you were thinking of?

in particular, I'm not totally sure why ast::ExprKind::Err(_) | ast::ExprKind::Dummy return Err(RewriteError::Unknown), but ast::TyKind::Dummy | ast::TyKind::Err(_) return Ok(context.snippet(self.span).to_owned()). I kept doing that for DirectConstArg, but, yeah.

i would expect this codepath to actually be unreachable. direct_const_arg! is a macro call in the AST and rustfmt will see the unexpanded AST so we'll never encounter a DirectConstArg expr/ty 🤔 does ICEing here cause any issues?

oh this is the:

rustfmt tries to parse macro arguments when formatting macros, so it's not
totally impossible for rustfmt to come across one of these nodes when formatting
a file

thats funny

BoxyUwU

good stuffs

View changes since this review

BoxyUwU · 2026-07-01T12:38:10Z

-                rhs: Some(self.parse_expr_anon_const(|_, _| MgcaDisambiguation::Direct)?),
-            },
+            (true, true) => {
+                ConstItemRhsKind::TypeConst { rhs: Some(self.parse_expr_anon_const()?) }


we should track somewhere to stop parsing type const rhs' differently than normal const items I think :3 this goes hand in hand with i guess the stuff about lowering the rhs of type consts as if they were direct'd?

precisely and exactly. very much on my todo list for the followup I was talking about!

BoxyUwU · 2026-07-01T12:38:47Z

-                self.with_parent(parent, |this| visit::walk_anon_const(this, constant));
-            }
-        };
+        let parent =


hurray less def collector and parsing jank 😌

BoxyUwU · 2026-07-01T12:40:28Z

+    /// it cannot.
    #[instrument(level = "debug", skip(self), ret)]
-    fn lower_expr_to_const_arg_direct(&mut self, expr: &Expr) -> hir::ConstArg<'hir> {
+    fn try_lower_expr_to_const_arg_direct(


this fn is like slightly scuffed but I need to think a bit about why that is and what an alternative might be :3

it's SO scuffed, and it's gonna get worse once we introduce macroful gca.

the main issue IMO is that we need a separate "check" and "actually do" phase, because we could fail several layers deep - e.g. we're inside a tuple, ((lowering, stuff), (and + then + we + error)), if we have already lowered and allocated arena memory when lowering (lowering, stuff), we cannot then bail out when we encounter the addition expr, because then all those generated IDs and arena memory and stuff would get unused.

BoxyUwU · 2026-07-01T12:45:44Z

+            ExprKind::Tup(exprs) if is_mgca => {
+                if check_only {
+                    for expr in exprs {
+                        let _ = self.try_lower_expr_to_const_arg_direct(expr, None, check_only)?;


iirc the reason we recurse into tuple elements but not path arguments is that we can't support (N, 1 + 1) without (N, const { 1 + 1 }) because we dont want to make a defid for all tuple element exprs in advance so that we can reuse the defid here

should write that down somewhere in here as the inconsistency between paths and other exprs feels slightly weird :3

View changes since the review

yeah. if we generated defids for everything, we wouldn't need this weird separate "check" and "actually do" phases, because we could always bail to representing things as anon consts if we fail to lower some later tuple element after successfully lowering previous tuple elements, and (N, 1 + 1) would sorta implicitly have a const { 1 + 1 } block.

... but generating defids for everything is, Not Great

BoxyUwU · 2026-07-01T14:37:28Z

-                    },
-                    _ => false,
-                }
+                && matches!(tcx.hir_node_by_def_id(local_id), hir::Node::ConstArg(_))


it would somewhat not surprise me if this causes ICEs, I would expect that if we have these defids in the parent tree then we actually do need to encode them 🤔

View changes since the review

BoxyUwU · 2026-07-01T14:40:56Z

+#![feature(min_generic_const_args)]
+#![allow(incomplete_features)]
+pub struct S<const N: usize>;
+pub fn f() -> S<{ const { 1 + 1 } }> {


is this an anon const with a const block inside it? can we have comment about what we expect this to lower to :3

View changes since the review

BoxyUwU

can we get a test that using direct_const_arg without any feature enabled gives a feature gate error even when using it in const arg position, e.g. fn foo<const N: usize>() -> [(); direct_const_arg!(N)] should error

View changes since this review

Shourya742 · 2026-07-01T14:49:18Z

+    let mut parser = cx.new_parser_from_tts(tts);
+    let expr = match parser.parse_expr() {
+        Ok(parsed) => parsed,
+        Err(err) => {
+            return ExpandResult::Ready(DummyResult::any(span, err.emit()));
+        }
+    };


I have this question, like do we expect the direct_const_arg! to contain multiple expressions?

View changes since the review

good point! fixed now :3

BoxyUwU · 2026-07-06T19:33:57Z

r=me if CI passes

khyperia · 2026-07-07T05:17:25Z

@bors r=BoxyUwU

rust-bors · 2026-07-07T05:17:28Z

📌 Commit 7f39e9f has been approved by BoxyUwU

It is now in the queue for this repository.

@BoxyUwU

allow mGCA const arguments to fall back to anon consts makes good progress on rust-lang/project-const-generics#108 `min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?" Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context) on **stable**, the full list of things can be directly represented is (... it's just the one thing) - paths to generic const parameters on `main`, under mGCA, **before** this PR: - absolutely everything, if something cannot be represented directly, compiler error - `const { }` gives you an escape hatch to go back to being an anon const on macro**ful** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro on macro**less** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro (not *particularly* useful under macro**less** gca) - struct expressions, arrays, blah blah - currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...) this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above). r? @BoxyUwU

…uwer Rollup of 18 pull requests Successful merges: - #157385 (Enable Enzyme on x86_64-apple) - #157561 (rustdoc: do not include extra stuff in span) - #158179 (std: unconditionally use `preadv`/`pwritev` on AArch64 macOS) - #158617 (allow mGCA const arguments to fall back to anon consts) - #158621 (disallow `extern "custom"` on wasm and spirv targets) - #158690 (delegation: support mapping of all arguments with `Self` type) - #158696 (Rename some `body_id` to `body_def_id`) - #158697 (Fixes for QNX SDP 8) - #158760 (Clarify that `LocalKey::try_with` may return `AccessError`) - #157801 (Rewrite safety requirements for `Allocator` impls) - #158333 (Fix typetree generation for differentiated functions) - #158646 (powerpc64le_unknown_freebsd.rs: link with -lgcc) - #158701 ( diagnostics: suggest type annotation for closure params on HRTB FnOnce mismatch) - #158791 (Avoid unused braces lint for macro generated arguments) - #158802 (Use `ci-mirrors` in `armhf-gnu` for {busybox, ubuntu rootfs} artifacts) - #158841 (Avoid final override ICE for RPITIT associated types) - #158889 (tests: catch up with LLVM returning f128 on the stack) - #158905 (delegation: add constraints to new generic args)

…uwer Rollup of 19 pull requests Successful merges: - #156016 (view-types: store view types in the AST) - #157385 (Enable Enzyme on x86_64-apple) - #158179 (std: unconditionally use `preadv`/`pwritev` on AArch64 macOS) - #158621 (disallow `extern "custom"` on wasm and spirv targets) - #158690 (delegation: support mapping of all arguments with `Self` type) - #158696 (Rename some `body_id` to `body_def_id`) - #158697 (Fixes for QNX SDP 8) - #158760 (Clarify that `LocalKey::try_with` may return `AccessError`) - #157801 (Rewrite safety requirements for `Allocator` impls) - #158085 (rustdoc: Fix sidebar heading order) - #158333 (Fix typetree generation for differentiated functions) - #158646 (powerpc64le_unknown_freebsd.rs: link with -lgcc) - #158701 ( diagnostics: suggest type annotation for closure params on HRTB FnOnce mismatch) - #158791 (Avoid unused braces lint for macro generated arguments) - #158802 (Use `ci-mirrors` in `armhf-gnu` for {busybox, ubuntu rootfs} artifacts) - #158841 (Avoid final override ICE for RPITIT associated types) - #158889 (tests: catch up with LLVM returning f128 on the stack) - #158905 (delegation: add constraints to new generic args) - #158922 (tests: clean up over-constraint on LLVM feature count) Failed merges: - #158617 (allow mGCA const arguments to fall back to anon consts)

rustbot · 2026-07-08T05:55:50Z

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.

khyperia · 2026-07-08T08:34:56Z

@bors r=BoxyUwU

third time's the charm?

rust-bors · 2026-07-08T08:34:59Z

📌 Commit 67986af has been approved by BoxyUwU

It is now in the queue for this repository.

@BoxyUwU

allow mGCA const arguments to fall back to anon consts makes good progress on rust-lang/project-const-generics#108 `min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?" Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context) on **stable**, the full list of things can be directly represented is (... it's just the one thing) - paths to generic const parameters on `main`, under mGCA, **before** this PR: - absolutely everything, if something cannot be represented directly, compiler error - `const { }` gives you an escape hatch to go back to being an anon const on macro**ful** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro on macro**less** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro (not *particularly* useful under macro**less** gca) - struct expressions, arrays, blah blah - currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...) this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above). r? @BoxyUwU

@BoxyUwU

allow mGCA const arguments to fall back to anon consts makes good progress on rust-lang/project-const-generics#108 `min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?" Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context) on **stable**, the full list of things can be directly represented is (... it's just the one thing) - paths to generic const parameters on `main`, under mGCA, **before** this PR: - absolutely everything, if something cannot be represented directly, compiler error - `const { }` gives you an escape hatch to go back to being an anon const on macro**ful** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro on macro**less** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro (not *particularly* useful under macro**less** gca) - struct expressions, arrays, blah blah - currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...) this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above). r? @BoxyUwU

…uwer Rollup of 18 pull requests Successful merges: - #158871 (add relnotes for 1.97.0) - #150946 (intrinsics: Add a fallback for non-const libm float functions) - #158617 (allow mGCA const arguments to fall back to anon consts) - #158645 (Fix splat ICEs and ban it in closures) - #158655 (Fix coroutine MIR saved local remapping) - #158666 (Carry the `b_offset` inside `BackendRepr::ScalarPair`) - #158920 (Update wasm-component-ld to 0.5.26) - #158926 (wrapping_sh* methods: clarify underspecified reference) - #158927 (add core test run with `-Zforce-intrinsic-fallback`) - #151379 (Stabilize `VecDeque::retain_back` from `truncate_front`) - #158807 (Add regression test for CString::clone_into unwind safety) - #158862 (Fix the span for parameter suggestion ) - #158883 (tests: fix enum-match.rs to handle LLVM 23) - #158894 (Make the ordering of non-terminal binds in ambiguity error messages deterministic) - #158902 (add codegen test for range length bound propagation) - #158913 (Update `browser-ui-test` version to `0.24.1`) - #158935 (std: support real fd methods on Emscripten) - #158951 (Merge three `MaxUniverse`s into one)

@BoxyUwU

allow mGCA const arguments to fall back to anon consts makes good progress on rust-lang/project-const-generics#108 `min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?" Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context) on **stable**, the full list of things can be directly represented is (... it's just the one thing) - paths to generic const parameters on `main`, under mGCA, **before** this PR: - absolutely everything, if something cannot be represented directly, compiler error - `const { }` gives you an escape hatch to go back to being an anon const on macro**ful** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro on macro**less** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro (not *particularly* useful under macro**less** gca) - struct expressions, arrays, blah blah - currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...) this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above). r? @BoxyUwU

@BoxyUwU

allow mGCA const arguments to fall back to anon consts makes good progress on rust-lang/project-const-generics#108 `min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?" Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context) on **stable**, the full list of things can be directly represented is (... it's just the one thing) - paths to generic const parameters on `main`, under mGCA, **before** this PR: - absolutely everything, if something cannot be represented directly, compiler error - `const { }` gives you an escape hatch to go back to being an anon const on macro**ful** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro on macro**less** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro (not *particularly* useful under macro**less** gca) - struct expressions, arrays, blah blah - currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...) this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above). r? @BoxyUwU

…uwer Rollup of 25 pull requests Successful merges: - #158871 (add relnotes for 1.97.0) - #158968 (stdarch subtree update) - #154445 (rustdoc: Represent `--output-format=json` coverage and ir differently) - #156370 (Reject linked dylib EII default overrides) - #157153 (allow `Allocator`s to be used as `#[global_allocator]`s) - #158495 (Rename HAS_CT_PROJECTION to HAS_CONST_ALIAS) - #158617 (allow mGCA const arguments to fall back to anon consts) - #158645 (Fix splat ICEs and ban it in closures) - #158655 (Fix coroutine MIR saved local remapping) - #158666 (Carry the `b_offset` inside `BackendRepr::ScalarPair`) - #158912 (Introduce new bootstrap config section for PGO configuration) - #158920 (Update wasm-component-ld to 0.5.26) - #158926 (wrapping_sh* methods: clarify underspecified reference) - #158927 (add core test run with `-Zforce-intrinsic-fallback`) - #158932 (Do not build the compiler when invoking `x perf compare`) - #158937 (Emit the emscripten entry point as `__main_argc_argv`) - #151379 (Stabilize `VecDeque::retain_back` from `truncate_front`) - #156548 ( Library support for aarch64-unknown-linux-pauthtest target) - #158307 (CI job for parallel frontend ui tests) - #158347 (Improve generic parameters handling for #[diagnostic::on_const]) - #158722 (delegation: do not always inherit `ConstArgHasType` predicates) - #158741 (Simplify `Option::into_flat_iter` signature) - #158807 (Add regression test for CString::clone_into unwind safety) - #158862 (Fix the span for parameter suggestion ) - #158883 (tests: fix enum-match.rs to handle LLVM 23)

@BoxyUwU

allow mGCA const arguments to fall back to anon consts makes good progress on rust-lang/project-const-generics#108 `min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?" Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context) on **stable**, the full list of things can be directly represented is (... it's just the one thing) - paths to generic const parameters on `main`, under mGCA, **before** this PR: - absolutely everything, if something cannot be represented directly, compiler error - `const { }` gives you an escape hatch to go back to being an anon const on macro**ful** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro on macro**less** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro (not *particularly* useful under macro**less** gca) - struct expressions, arrays, blah blah - currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...) this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above). r? @BoxyUwU

Rollup of 25 pull requests Successful merges: - #158871 (add relnotes for 1.97.0) - #158968 (stdarch subtree update) - #157690 (codegen_ssa: pack small const aggregates into immediate stores) - #158541 (Move `std::io::Write` to `core::io`) - #154445 (rustdoc: Represent `--output-format=json` coverage and ir differently) - #156370 (Reject linked dylib EII default overrides) - #157153 (allow `Allocator`s to be used as `#[global_allocator]`s) - #158495 (Rename HAS_CT_PROJECTION to HAS_CONST_ALIAS) - #158617 (allow mGCA const arguments to fall back to anon consts) - #158645 (Fix splat ICEs and ban it in closures) - #158655 (Fix coroutine MIR saved local remapping) - #158666 (Carry the `b_offset` inside `BackendRepr::ScalarPair`) - #158870 (std: merge the unix-like io::error modules into one file) - #158920 (Update wasm-component-ld to 0.5.26) - #158926 (wrapping_sh* methods: clarify underspecified reference) - #158927 (add core test run with `-Zforce-intrinsic-fallback`) - #158932 (Do not build the compiler when invoking `x perf compare`) - #158937 (Emit the emscripten entry point as `__main_argc_argv`) - #151379 (Stabilize `VecDeque::retain_back` from `truncate_front`) - #156144 (Better docs for PartialEq (includes macro rename)) - #156548 ( Library support for aarch64-unknown-linux-pauthtest target) - #158307 (CI job for parallel frontend ui tests) - #158347 (Improve generic parameters handling for #[diagnostic::on_const]) - #158722 (delegation: do not always inherit `ConstArgHasType` predicates) - #158741 (Simplify `Option::into_flat_iter` signature)

rustbot assigned BoxyUwU Jun 30, 2026

ytmimi reviewed Jun 30, 2026

View reviewed changes

khyperia force-pushed the gca-syntax-flip branch from f0b3a40 to 4c7a81e Compare July 1, 2026 05:42

BoxyUwU reviewed Jul 1, 2026

View reviewed changes

khyperia force-pushed the gca-syntax-flip branch from 4c7a81e to 68d2d7e Compare July 1, 2026 14:03

BoxyUwU reviewed Jul 1, 2026

View reviewed changes

Shourya742 reviewed Jul 1, 2026

View reviewed changes

khyperia force-pushed the gca-syntax-flip branch 2 times, most recently from eb61cdf to 44acd42 Compare July 1, 2026 15:31

khyperia mentioned this pull request Jul 4, 2026

merge DefKind::InlineConst into AnonConst #158767

Open

This comment has been minimized.

Sign in to view

khyperia force-pushed the gca-syntax-flip branch from 44acd42 to 7f39e9f Compare July 6, 2026 19:25

This comment has been minimized.

Sign in to view

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 7, 2026

m-ou-se mentioned this pull request Jul 7, 2026

Rollup of 8 pull requests #158906

Closed

JonathanBrouwer mentioned this pull request Jul 7, 2026

Rollup of 19 pull requests #158924

Merged

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 8, 2026

This comment has been minimized.

Sign in to view

allow mGCA const arguments to fall back to anon consts

67986af

khyperia force-pushed the gca-syntax-flip branch from 7f39e9f to 67986af Compare July 8, 2026 05:55

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 8, 2026

GuillaumeGomez mentioned this pull request Jul 8, 2026

Rollup of 16 pull requests #158953

Closed

BoxyUwU mentioned this pull request Jul 8, 2026

Handle nested inline consts in const argument checks #158640

Open

JonathanBrouwer mentioned this pull request Jul 8, 2026

Rollup of 18 pull requests #158958

Closed

BoxyUwU mentioned this pull request Jul 8, 2026

Reject static item as direct const generic arg #158479

Open

JonathanBrouwer mentioned this pull request Jul 8, 2026

Rollup of 25 pull requests #158973

Closed

JonathanBrouwer mentioned this pull request Jul 8, 2026

Rollup of 25 pull requests #158977

Closed

jhpratt mentioned this pull request Jul 8, 2026

Rollup of 25 pull requests #158986

Closed

Uh oh!

Uh oh!

Conversation

khyperia commented Jun 30, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 30, 2026

Uh oh!

rustbot commented Jun 30, 2026

Uh oh!

ytmimi left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Jul 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Jul 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Jul 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Shourya742 Jul 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

BoxyUwU commented Jul 6, 2026

Uh oh!

khyperia commented Jul 7, 2026

Uh oh!

rust-bors Bot commented Jul 7, 2026

Uh oh!

This comment has been minimized.

rustbot commented Jul 8, 2026

Uh oh!

khyperia commented Jul 8, 2026

Uh oh!

rust-bors Bot commented Jul 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

khyperia commented Jun 30, 2026 •

edited by rustbot

Loading

ytmimi left a comment •

edited by rustbot

Loading

BoxyUwU left a comment •

edited by rustbot

Loading

BoxyUwU Jul 1, 2026 •

edited by rustbot

Loading

BoxyUwU Jul 1, 2026 •

edited by rustbot

Loading

BoxyUwU Jul 1, 2026 •

edited by rustbot

Loading

BoxyUwU left a comment •

edited by rustbot

Loading

Shourya742 Jul 1, 2026 •

edited by rustbot

Loading