type system const items via direct rhs by khyperia · Pull Request #162179 · rust-lang/rust

khyperia · 2026-09-02T10:02:14Z

see also zulip thread: #project-const-generics > implementing assoc consts as direct args

a const item with a direct! rhs is now a type system transparent direct const, similar to a type const:

const C: T = core::direct_const_arg!(V);

if the macroless feature is enabled, the macroless heuristic also applies here

this PR puts us in an awkward middle ground, between the present world with type const, and the future of GCA as discussed in this zulip thread: #project-const-generics > talkies at last

tl;dr we're yeeting type const and replacing it with const C: T = gca!(V);, and with this PR, both syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much!

some notes on the change:

the is_type_const boolean on the DefKind now corresponds to whether the type const syntax is used, not whether it is a type system transparent const
the const_of_item query now returns Option, and is Some when it is a type system transparent direct const.
- it is a little spicy that const_of_item returns None if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning None is a bit more convenient. API design is hard, idk.
the TyCtxt method is_direct_const is true if it's either a type const, or if it's a direct const
- this logic will eventually change to: is true if it either has the #[always_gca] attribute, or if it has a gca! rhs.
should we serialize the const_of_item query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever.

r? @BoxyUwU

rustbot · 2026-09-02T10:02:19Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

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 match checking

cc @Nadrieril

HIR ty lowering was modified

cc @fmease

changes to the core type system

cc @lcnr

rustbot · 2026-09-02T10:02:22Z

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

BoxyUwU

very sick and cool :3

View changes since this review

BoxyUwU · 2026-09-02T10:14:43Z

@@ -2683,19 +2683,41 @@ impl<'hir> LoweringContext<'_, 'hir> {
    ) -> hir::ConstItemRhs<'hir> {
        match (body, kind) {
            (body, ConstItemKind::Body) => {


In the long tail of history I suppose we wont have a ConstItemKind to match on because they'll all be the same kind?

correct, ConstItemKind gets nuked, and this method, lower_const_item_rhs, will only be this arm of this match statement.

BoxyUwU · 2026-09-02T10:24:01Z

    def_id: LocalDefId,
    item_ty: Ty<'tcx>,
-    has_value: bool,
-) -> Result<(), ErrorGuaranteed> {


why yeet the Result?

no reason, there was no ? or return Err or anything in this method, we were always returning Ok(()), so why not yeet Result

BoxyUwU · 2026-09-02T10:25:49Z

+                Ty::new_error_with_message(
+                    tcx,
+                    ty_span,
+                    "constant with `type const` requires an explicit type",


I assume this isn't necessarily always a type const nowadays?

yeahh. bunch of comments that need to be updated too, but with so much up in the air right now, I've kind of put off changing this wording to after type const is fully yeeted, and we can just talk about consts with a gca!() rhs. kind of a pain to try to invent some wording like "constant with type const or direct_const_arg!() rhs or is a macroless direct const requires an explicit type" that's not a mouthful, but if you think it's worth it I can poke around~

reasonable to put this off until the full thing is done

BoxyUwU · 2026-09-02T10:27:38Z

+            kind: hir::TraitItemKind::Const(_, ct), ..
+        }) => ct?,
+        hir::Node::ImplItem(&hir::ImplItem { kind: hir::ImplItemKind::Const(.., ct), .. }) => ct,
+        hir::Node::AnonConst(..) | hir::Node::ConstBlock(..) => {


why for anon const/const block 🤔 I would expect us to not call this query on these defkinds but I guess we do in practice for some reason?

yeah, like, the debug assert in eval_in_interpreter, thir_body, the par_hir_body_owners call in rustc_hir_analysis/lib.rs, the rustc_monomorphize/collector.rs, buncha wonky places that don't particularly care about const items vs anon consts, and it just clutters the caller to check for anon consts. but also totally reasonable to guard against anon consts there too, and ICE in const_of_item for anon consts instead.

BoxyUwU · 2026-09-02T10:28:48Z

                record!(self.tables.anon_const_kind[def_id] <- self.tcx.anon_const_kind(def_id));
            }
-            if should_encode_const_of_item(self.tcx, def_id, def_kind) {
+            if let DefKind::Const { .. } | DefKind::AssocConst { .. } | DefKind::AnonConst =


I guess this is the same question as above, why encode it for AnonConst :3

yeah, also, related comment in the PR description:

should we serialize the const_of_item query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever.

BoxyUwU · 2026-09-02T10:33:02Z

+    ///
+    /// This is NOT the same as whether the `def_id` can be represented in/used by the type system.
+    /// For that, you probably want to ask `const_of_item().is_some()`.
    pub fn is_type_const(self, def_id: impl IntoQueryKey<DefId>) -> bool {


U changed elsewhere to be is_type_const_syntax right? I would do similar here to make it clear this is not so much a semantic thing any longer (though it may not matter much since type const yeet soon)

mm yeah, when developing this PR I had this called is_type_const_syntax to make sure I looked at all callsites, but I renamed it back just before submit. (grepping is_type_const_syntax is zero hits, it's not a thing in this PR)

but yea, tbh reasonable to keep that change instead of reverting it, if it's useful in this PR's development it's probably just straight up useful always and should be kept :P

also means that I get to review every call site too :3

BoxyUwU · 2026-09-02T10:36:10Z

-            if tcx.is_type_const(def_id) {
+            // Under generic_const_args, `def_id` might be a trait alias that is a regular const,
+            // but is `impl`d as a directly represented const. We do not know whether it is here, so
+            // we must use type system normalization for all consts under generic_const_args.


In theory we could only do this for projections, not free/inherent consts since those we can just look at const_of_item for during MIR building. But I don't think that matters 🤔

I'm not confident in whether I consider this to be a hack or a principled fix tbh 😅 It's probably a bit in the middle I suppose... Can you add a FIXME to revisit this before stabilization even if it's fine for now and may even wind up being the long term thing we do

o though pls use a term other than "trait alias" since that means something else

BoxyUwU · 2026-09-02T10:36:22Z

+    {
+        debug_assert!(
+            tcx.const_of_item(owner_def.to_def_id()).is_none(),
+            "thir_body queried for type_const"


probably not always a type const right?

BoxyUwU · 2026-09-02T10:36:32Z

+    {
+        debug_assert!(
+            tcx.const_of_item(def).is_none(),
+            "CTFE tried to evaluate type-const: {:?}",


probably not always a type const right?

BoxyUwU · 2026-09-02T10:38:46Z

-        let const_value = if alias_const.kind.is_type_const(self.tcx) {
+        // Under generic_const_args, `alias_const` might be a trait alias that is a regular const,
+        // but is `impl`d as a directly represented const. We do not know whether it is here, so we
+        // must use type system normalization for all consts under generic_const_args.


Suggested change

// must use type system normalization for all consts under generic_const_args.

// must use type system normalization for all consts under generic_const_args.

//

// We probably want to always use type system norm on stable too

// but that would be a breaking change so right now we limit it to

// just GCA.

maybe 🤔

it would be worth linking to something but im not sure what, i dont know that I have a good write up anywhere of plans for const patterns. but I should write one

you made an issue for this here, maybe this link? rust-lang/project-const-generics#105 (there's nothing really in this issue at the moment though)

on a tangent, more than just const patterns, I think a writeup for the uuuh compiler/rustc_mir_build/src/builder/expr/as_constant.rs change would be lovely. when I was yapping with lcnr about this, that one in particular took a lot to communicate/sync on. like, all the stuff around padding bytes and multiple value representations and whatever and more importantly, how we plan to address those issues, big oof, rough times. (lcnr had the idea to spec const items as roundtripping their result through a valtree or something, but yea, no clue myself)

khyperia · 2026-09-02T13:01:45Z

@rustbot author

khyperia · 2026-09-03T08:23:49Z

@rustbot ready

changed const_of_item to ICE on anon consts

BoxyUwU · 2026-09-03T09:07:03Z

coolio, r=me once #162168 has landed and you've rebased it away

BoxyUwU · 2026-09-03T10:19:04Z

@rustbot author

rustbot · 2026-09-04T06:04:57Z

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-09-04T11:20:12Z

@bors r=BoxyUwU

rust-bors · 2026-09-04T11:20:14Z

📌 Commit b61efec has been approved by BoxyUwU

It is now in the queue for this repository.

@BoxyUwU

type system const items via direct rhs fixes rust-lang#161264 see also zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) a const item with a `direct!` rhs is now a type system transparent direct const, similar to a type const: ```rust const C: T = core::direct_const_arg!(V); ``` if the macroless feature is enabled, the macroless heuristic also applies here this PR puts us in an awkward middle ground, between the present world with `type const`, and the future of GCA as discussed in this zulip thread: [#project-const-generics > talkies at last](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/with/620616030) tl;dr we're yeeting `type const` and replacing it with `const C: T = gca!(V);`, and with this PR, *both* syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much! some notes on the change: - the is_type_const boolean on the DefKind now corresponds to whether the `type const` syntax is used, *not* whether it is a type system transparent const - the `const_of_item` query now returns `Option`, and is `Some` when it is a type system transparent direct const. - it is a little spicy that `const_of_item` returns `None` if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning `None` is a bit more convenient. API design is hard, idk. - the `TyCtxt` method `is_direct_const` is true if it's either a `type const`, or if it's a direct const - this logic will eventually change to: is true if it either has the `#[always_gca]` attribute, or if it has a `gca!` rhs. - should we serialize the `const_of_item` query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever. r? @BoxyUwU

@BoxyUwU

type system const items via direct rhs fixes rust-lang#161264 see also zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) a const item with a `direct!` rhs is now a type system transparent direct const, similar to a type const: ```rust const C: T = core::direct_const_arg!(V); ``` if the macroless feature is enabled, the macroless heuristic also applies here this PR puts us in an awkward middle ground, between the present world with `type const`, and the future of GCA as discussed in this zulip thread: [#project-const-generics > talkies at last](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/with/620616030) tl;dr we're yeeting `type const` and replacing it with `const C: T = gca!(V);`, and with this PR, *both* syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much! some notes on the change: - the is_type_const boolean on the DefKind now corresponds to whether the `type const` syntax is used, *not* whether it is a type system transparent const - the `const_of_item` query now returns `Option`, and is `Some` when it is a type system transparent direct const. - it is a little spicy that `const_of_item` returns `None` if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning `None` is a bit more convenient. API design is hard, idk. - the `TyCtxt` method `is_direct_const` is true if it's either a `type const`, or if it's a direct const - this logic will eventually change to: is true if it either has the `#[always_gca]` attribute, or if it has a `gca!` rhs. - should we serialize the `const_of_item` query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever. r? @BoxyUwU

@BoxyUwU

type system const items via direct rhs fixes rust-lang#161264 see also zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) a const item with a `direct!` rhs is now a type system transparent direct const, similar to a type const: ```rust const C: T = core::direct_const_arg!(V); ``` if the macroless feature is enabled, the macroless heuristic also applies here this PR puts us in an awkward middle ground, between the present world with `type const`, and the future of GCA as discussed in this zulip thread: [#project-const-generics > talkies at last](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/with/620616030) tl;dr we're yeeting `type const` and replacing it with `const C: T = gca!(V);`, and with this PR, *both* syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much! some notes on the change: - the is_type_const boolean on the DefKind now corresponds to whether the `type const` syntax is used, *not* whether it is a type system transparent const - the `const_of_item` query now returns `Option`, and is `Some` when it is a type system transparent direct const. - it is a little spicy that `const_of_item` returns `None` if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning `None` is a bit more convenient. API design is hard, idk. - the `TyCtxt` method `is_direct_const` is true if it's either a `type const`, or if it's a direct const - this logic will eventually change to: is true if it either has the `#[always_gca]` attribute, or if it has a `gca!` rhs. - should we serialize the `const_of_item` query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever. r? @BoxyUwU

Rollup of 25 pull requests Successful merges: - #159074 ([PAC] FnAbi, llvm.ptrauth.resign and Session API change (2/8)) - #159792 (A more readable debug map for IndexMaps) - #161895 (std::sys::pal::sgx: fix mismatched alloc/free alignment) - #161900 (bootstrap: Include feature-gated items in bootstrap tool docs) - #161940 (Promote `wasm32-wasip3` to a tier 2 target) - #162072 (Add new Tier-3 target: `powerpc64-sony-ps3`) - #162179 (type system const items via direct rhs) - #162277 (Introduce `rustc_middle::middel::resolve`) - #162285 (box: fixup map/try_map deallocate calls) - #162286 (string: don't unwind prematurely) - #162289 (alloc: a bunch of safety comments) - #162292 (Update `askama` version to `0.16.1`) - #160509 (Remove `RegionExt`; move methods to `Region` in `rustc_type_ir`) - #160906 (Suggest usize instead of placeholder type for array length constants) - #160936 (traits: Represent live alias arguments as bitsets) - #161400 (Improve diagnostics for references to closures) - #161656 (Suggest mutable references for FnMut closure arguments) - #161711 (Add more splat fn type tests) - #161786 (Make `tcx.def_id_partial_cmp` public) - #161953 (sanitizers: Implicitly disable mutually exclusive sanitizers) - #162155 (add suggestion for `rustc_allowed_through_unstable_modules` attribute) - #162212 (Implement `Rng` for `Box`) - #162246 (Fix incorrect meta span) - #162266 (std: fix typo) - #162291 (Add regression test from 1.98.1)

@BoxyUwU

type system const items via direct rhs fixes rust-lang#161264 see also zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) a const item with a `direct!` rhs is now a type system transparent direct const, similar to a type const: ```rust const C: T = core::direct_const_arg!(V); ``` if the macroless feature is enabled, the macroless heuristic also applies here this PR puts us in an awkward middle ground, between the present world with `type const`, and the future of GCA as discussed in this zulip thread: [#project-const-generics > talkies at last](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/with/620616030) tl;dr we're yeeting `type const` and replacing it with `const C: T = gca!(V);`, and with this PR, *both* syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much! some notes on the change: - the is_type_const boolean on the DefKind now corresponds to whether the `type const` syntax is used, *not* whether it is a type system transparent const - the `const_of_item` query now returns `Option`, and is `Some` when it is a type system transparent direct const. - it is a little spicy that `const_of_item` returns `None` if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning `None` is a bit more convenient. API design is hard, idk. - the `TyCtxt` method `is_direct_const` is true if it's either a `type const`, or if it's a direct const - this logic will eventually change to: is true if it either has the `#[always_gca]` attribute, or if it has a `gca!` rhs. - should we serialize the `const_of_item` query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever. r? @BoxyUwU

Rollup of 25 pull requests Successful merges: - #159074 ([PAC] FnAbi, llvm.ptrauth.resign and Session API change (2/8)) - #159792 (A more readable debug map for IndexMaps) - #160745 (make closures act like MaybeDangling) - #161895 (std::sys::pal::sgx: fix mismatched alloc/free alignment) - #161940 (Promote `wasm32-wasip3` to a tier 2 target) - #162072 (Add new Tier-3 target: `powerpc64-sony-ps3`) - #162179 (type system const items via direct rhs) - #162277 (Introduce `rustc_middle::middel::resolve`) - #162285 (box: fixup map/try_map deallocate calls) - #162286 (string: don't unwind prematurely) - #162289 (alloc: a bunch of safety comments) - #162292 (Update `askama` version to `0.16.1`) - #160509 (Remove `RegionExt`; move methods to `Region` in `rustc_type_ir`) - #160906 (Suggest usize instead of placeholder type for array length constants) - #160936 (traits: Represent live alias arguments as bitsets) - #161400 (Improve diagnostics for references to closures) - #161656 (Suggest mutable references for FnMut closure arguments) - #161711 (Add more splat fn type tests) - #161786 (Make `tcx.def_id_partial_cmp` public) - #161953 (sanitizers: Implicitly disable mutually exclusive sanitizers) - #162155 (add suggestion for `rustc_allowed_through_unstable_modules` attribute) - #162212 (Implement `Rng` for `Box`) - #162246 (Fix incorrect meta span) - #162266 (std: fix typo) - #162291 (Add regression test from 1.98.1)

@BoxyUwU

type system const items via direct rhs fixes rust-lang#161264 see also zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) a const item with a `direct!` rhs is now a type system transparent direct const, similar to a type const: ```rust const C: T = core::direct_const_arg!(V); ``` if the macroless feature is enabled, the macroless heuristic also applies here this PR puts us in an awkward middle ground, between the present world with `type const`, and the future of GCA as discussed in this zulip thread: [#project-const-generics > talkies at last](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/with/620616030) tl;dr we're yeeting `type const` and replacing it with `const C: T = gca!(V);`, and with this PR, *both* syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much! some notes on the change: - the is_type_const boolean on the DefKind now corresponds to whether the `type const` syntax is used, *not* whether it is a type system transparent const - the `const_of_item` query now returns `Option`, and is `Some` when it is a type system transparent direct const. - it is a little spicy that `const_of_item` returns `None` if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning `None` is a bit more convenient. API design is hard, idk. - the `TyCtxt` method `is_direct_const` is true if it's either a `type const`, or if it's a direct const - this logic will eventually change to: is true if it either has the `#[always_gca]` attribute, or if it has a `gca!` rhs. - should we serialize the `const_of_item` query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever. r? @BoxyUwU

@BoxyUwU

type system const items via direct rhs fixes rust-lang#161264 see also zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) a const item with a `direct!` rhs is now a type system transparent direct const, similar to a type const: ```rust const C: T = core::direct_const_arg!(V); ``` if the macroless feature is enabled, the macroless heuristic also applies here this PR puts us in an awkward middle ground, between the present world with `type const`, and the future of GCA as discussed in this zulip thread: [#project-const-generics > talkies at last](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/with/620616030) tl;dr we're yeeting `type const` and replacing it with `const C: T = gca!(V);`, and with this PR, *both* syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much! some notes on the change: - the is_type_const boolean on the DefKind now corresponds to whether the `type const` syntax is used, *not* whether it is a type system transparent const - the `const_of_item` query now returns `Option`, and is `Some` when it is a type system transparent direct const. - it is a little spicy that `const_of_item` returns `None` if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning `None` is a bit more convenient. API design is hard, idk. - the `TyCtxt` method `is_direct_const` is true if it's either a `type const`, or if it's a direct const - this logic will eventually change to: is true if it either has the `#[always_gca]` attribute, or if it has a `gca!` rhs. - should we serialize the `const_of_item` query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever. r? @BoxyUwU

Rollup of 27 pull requests Successful merges: - #159074 ([PAC] FnAbi, llvm.ptrauth.resign and Session API change (2/8)) - #159792 (A more readable debug map for IndexMaps) - #160745 (make closures act like MaybeDangling) - #161940 (Promote `wasm32-wasip3` to a tier 2 target) - #162030 (Prevent `--test` to be used in `rustdoc-html` testsuite) - #162072 (Add new Tier-3 target: `powerpc64-sony-ps3`) - #162179 (type system const items via direct rhs) - #162262 (Avoid manually instantiating some binders in error reporting with `-Znext-solver`) - #162277 (Introduce `rustc_middle::middel::resolve`) - #162285 (box: fixup map/try_map deallocate calls) - #162286 (string: don't unwind prematurely) - #162289 (alloc: a bunch of safety comments) - #162290 (abby test DSL: AliasTyOutlivesViaEnv) - #162292 (Update `askama` version to `0.16.1`) - #160509 (Remove `RegionExt`; move methods to `Region` in `rustc_type_ir`) - #160906 (Suggest usize instead of placeholder type for array length constants) - #160936 (traits: Represent live alias arguments as bitsets) - #161400 (Improve diagnostics for references to closures) - #161656 (Suggest mutable references for FnMut closure arguments) - #161711 (Add more splat fn type tests) - #161786 (Make `tcx.def_id_partial_cmp` public) - #161953 (sanitizers: Implicitly disable mutually exclusive sanitizers) - #162155 (add suggestion for `rustc_allowed_through_unstable_modules` attribute) - #162212 (Implement `Rng` for `Box`) - #162246 (Fix incorrect meta span) - #162266 (std: fix typo) - #162291 (Add regression test from 1.98.1)

@BoxyUwU

type system const items via direct rhs fixes rust-lang#161264 see also zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) a const item with a `direct!` rhs is now a type system transparent direct const, similar to a type const: ```rust const C: T = core::direct_const_arg!(V); ``` if the macroless feature is enabled, the macroless heuristic also applies here this PR puts us in an awkward middle ground, between the present world with `type const`, and the future of GCA as discussed in this zulip thread: [#project-const-generics > talkies at last](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/talkies.20at.20last/with/620616030) tl;dr we're yeeting `type const` and replacing it with `const C: T = gca!(V);`, and with this PR, *both* syntaxes are supported at the same time, which is weird and awkward. But, incremental improvement is good, doing the whole thing at once is too much! some notes on the change: - the is_type_const boolean on the DefKind now corresponds to whether the `type const` syntax is used, *not* whether it is a type system transparent const - the `const_of_item` query now returns `Option`, and is `Some` when it is a type system transparent direct const. - it is a little spicy that `const_of_item` returns `None` if there is no RHS rather than panicing - if it panics, it's vaguely annoying to guard against this in callsites, returning `None` is a bit more convenient. API design is hard, idk. - the `TyCtxt` method `is_direct_const` is true if it's either a `type const`, or if it's a direct const - this logic will eventually change to: is true if it either has the `#[always_gca]` attribute, or if it has a `gca!` rhs. - should we serialize the `const_of_item` query for anon consts, or just guard against the DefKind in some helper that returns the actually serialized query impl? Behavior is the same, idk perf jank or whatever. r? @BoxyUwU

rustbot assigned BoxyUwU Sep 2, 2026

rustbot added the WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) label Sep 2, 2026

BoxyUwU reviewed Sep 2, 2026

View reviewed changes

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Sep 2, 2026

khyperia force-pushed the direct-rhs-const branch from 56dc345 to 108442b Compare September 3, 2026 08:19

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 3, 2026

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Sep 3, 2026

BoxyUwU mentioned this pull request Sep 3, 2026

Full Const Generics rust-lang/goals#100

Open

7 tasks

This comment has been minimized.

Sign in to view

type system const items via direct rhs

b61efec

khyperia force-pushed the direct-rhs-const branch from 108442b to b61efec Compare September 4, 2026 06:04

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 Sep 4, 2026

JonathanBrouwer mentioned this pull request Sep 4, 2026

Rollup of 13 pull requests #162293

Closed

GuillaumeGomez mentioned this pull request Sep 4, 2026

Rollup of 25 pull requests #162297

Closed

GuillaumeGomez mentioned this pull request Sep 4, 2026

Rollup of 25 pull requests #162298

Closed

GuillaumeGomez mentioned this pull request Sep 4, 2026

Rollup of 25 pull requests #162300

Closed

GuillaumeGomez mentioned this pull request Sep 4, 2026

Rollup of 28 pull requests #162307

Closed

GuillaumeGomez mentioned this pull request Sep 4, 2026

Rollup of 27 pull requests #162308

Closed

JonathanBrouwer mentioned this pull request Sep 4, 2026

Rollup of 25 pull requests #162310

Open

-        // must use type system normalization for all consts under generic_const_args.
+        // must use type system normalization for all consts under generic_const_args.
+        //
+        // We probably want to always use type system norm on stable too
+        // but that would be a breaking change so right now we limit it to
+        // just GCA.

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Sep 2, 2026

Uh oh!

rustbot commented Sep 2, 2026

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!

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!

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!

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!

khyperia commented Sep 2, 2026

Uh oh!

khyperia commented Sep 3, 2026

Uh oh!

BoxyUwU commented Sep 3, 2026

Uh oh!

BoxyUwU commented Sep 3, 2026

Uh oh!

This comment has been minimized.

rustbot commented Sep 4, 2026

Uh oh!

khyperia commented Sep 4, 2026

Uh oh!

rust-bors Bot commented Sep 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

khyperia commented Sep 2, 2026 •

edited by rustbot

Loading

BoxyUwU left a comment •

edited by rustbot

Loading