explicitly track inherent const generic args kind by khyperia · Pull Request #161929 · rust-lang/rust

khyperia · 2026-08-28T13:37:50Z

in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under feature(generic_const_args)

see the new big doc comment in compiler/rustc_type_ir/src/const_kind.rs if you dunno what the heck I'm on about with "self args" vs "impl args" ✨

on a small note, the FIXME on alias_term_kind_from_def_id becomes even more relevant with this PR, ty::AliasConstInherentArgsKind is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable.

also, check_args_compatible is very spooky scary in that if you have a ty::Alias, you ought to use check_term_args_compatible, but nothing's stopping you from calling check_args_compatible with the term's DefId. I was unable to think up a clever API that would prevent this misuse.

and finally, I think some of these match statements could theoretically bug! on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later.

relevant tracking issue: rust-lang/project-const-generics#98

also very related to feature(inherent_associated_types): #8995 rust-lang/project-const-generics#71

relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: #155341

implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes #161264 (was working on adding support when I got sidetracked with this PR), see also this zulip thread: #project-const-generics > implementing assoc consts as direct args (is there an issue for this?)

r? @BoxyUwU

rustbot · 2026-08-28T13:37:53Z

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_sanitizers

cc @rcvalle

changes to the core type system

cc @lcnr

Some changes occurred in match checking

cc @Nadrieril

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

HIR ty lowering was modified

cc @fmease

changes to the core type system

cc @lcnr

khyperia · 2026-08-28T13:57:10Z

it is mildly annoying that ./x test tidy does not spellcheck, instead, tidy fails on CI the moment I push :c

(will fix later in a batch update with any PR feedback)

BoxyUwU · 2026-08-31T10:54:04Z

                            tcx,
                            trait_ty.def_id,
                            rebased_args,
+                            ty::AliasConstInherentArgsKind::Impl,


Why impl here. does this even encounter inherent associated consts 🤔

View changes since the review

correct, the value here is "dead code", there's a ty::AssocContainer::InherentImpl => bug!() above. ideally, we would not use new_from_def_id and instead construct the variants directly (and so wouldn't have to specify what happens for inherents), but, leaving that as the FIXME note already on new_from_def_id and doing that Later(tm)

anyway, I arbitrarily chose AliasConstInherentArgsKind::Impl because the args being passed in are rebased_args, i.e. impl-format args.

can you add a comment saying that this is theoretically unused (or better yet also assert that we don't encounter an Inherent assoc const defid here)

wait what am I even doing, I'm just gonna fix the fixme and do explicit construction in this one spot, it's always a ty here, never a const, so it's just, ty::AliasTerm::new(tcx, ty::AliasTermKind::ProjectionTy { def_id: trait_ty.def_id }, rebased_args).

ty::AliasTerm::new asserts the defid's defkind too (thanks to this very PR) so no need to assert here.

BoxyUwU · 2026-08-31T10:56:39Z


-    fn check_args_compatible(self, def_id: DefId, args: ty::GenericArgsRef<'tcx>) -> bool {
-        self.check_args_compatible(def_id, args)
+    fn check_term_args_compatible(


can we call this check_alias_term_args_compatible same w/ the debug assert one. i got confused when reading the call sites of them thinking this was more general than for just aliases :3

View changes since the review

BoxyUwU · 2026-08-31T11:08:29Z

                    match alias_const.kind {
-                        ty::AliasConstKind::Inherent { .. } => {
+                        ty::AliasConstKind::InherentSelf { .. }
+                        | ty::AliasConstKind::InherentImpl { .. } => {


I dont undestand how this can be correct 🤔 add_wf_preds_for_inherent_projection definitely expects Self form args since it converts them to impl form

View changes since the review

add_wf_preds_for_inherent_projection calls compute_inherent_assoc_term_args which returns the args as a no-op if it's already InherentConstImpl, so it could technically function. (compute_inherent_assoc_term_args returning early is kinda bad readability, the return is lexically buried in a match statement, I was considering adding a comment pointing out the early return to make it more visible, or something)

however, replacing this with ty::AliasConstKind::InherentImpl { .. } => panic!("blah") and running tests shows it's unused. I wrote in the PR description:

and finally, I think some of these match statements could theoretically bug! on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later.

to be honest, I'm not 100% sure if this ought to be a panic or if this is theoretically reachable, if you're confident it's unreachable I can replace it with a bug!.

Making it a bug! and then waiting for a test case for if it's reachable seems reasonable to me

BoxyUwU

r=me after the nits

View changes since this review

BoxyUwU · 2026-08-31T12:11:55Z

@rustbot author

BoxyUwU · 2026-08-31T14:52:04Z

@bors r+

rust-bors · 2026-08-31T14:52:07Z

📌 Commit 892c6bb has been approved by BoxyUwU

It is now in the queue for this repository.

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

…uwer Rollup of 12 pull requests Successful merges: - #162045 (`rust-analyzer` subtree update) - #162077 (compiler-builtins subtree update) - #137720 (support `#[target_feature(enable = ...)]` on `#[naked]` functions) - #160534 (stabilize smart pointer map functions) - #160551 (mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering) - #161929 (explicitly track inherent const generic args kind) - #162063 (Switch dist-aarch64-linux to EC2 and update dist-x86_64-linux) - #161937 (A series of Polonius Alpha refactors) - #162014 (Move more `rustdoc-html` tests using `--test` into the right folder) - #162051 (`rustc_feature` cleanups) - #162055 (remove `_{style}` recovery for diagnostic structs) - #162075 (Move track_caller on closures gating to attribute parsing)

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

@BoxyUwU

…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

…uwer Rollup of 16 pull requests Successful merges: - #137720 (support `#[target_feature(enable = ...)]` on `#[naked]` functions) - #160534 (stabilize smart pointer map functions) - #160551 (mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering) - #160989 (Make sin, cos, exp, exp2, log, log2, log10 generic) - #161861 (mir_build: Clarify parts of if-condition lowering) - #161929 (explicitly track inherent const generic args kind) - #162040 (bootstrap: stage0 to cbae9b4) - #162063 (Switch dist-aarch64-linux to EC2 and update dist-x86_64-linux) - #161353 (Add test for parallel compiler reproducible build) - #161937 (A series of Polonius Alpha refactors) - #162051 (`rustc_feature` cleanups) - #162055 (remove `_{style}` recovery for diagnostic structs) - #162075 (Move track_caller on closures gating to attribute parsing) - #162079 (std: implement `File::fsync` for Hermit) - #162097 (Deduplicate `InstrumentFnAttr`) - #162115 (fix typo in feature documentation)

@BoxyUwU

Rollup merge of #161929 - khyperia:explicitly-track-inherent-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: #8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: #155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes #161264 (was working on adding support when I got sidetracked with this PR), see also this 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) (is there an issue for this?) r? @BoxyUwU

lcnr · 2026-09-01T16:29:09Z

+        def_id: Self::DefId,
+        inherent_args: ty::AliasConstInherentArgsKind,
+    ) -> ty::AliasConstKind<'tcx> {
        match self.def_kind(def_id) {


why does this function exist? I guess we pass AliasConstInherentArgsKind in places which could be inherent constants but also other DefKinds?

yh, i remember having a similar question because it feels like kind of a code smell having the inherent_args param in cases where you might not actually have inherent aliases. but we have places that work with any def-id alias and the codepath needs ot handle both inherents and others iirc

yeah, there's been a FIXME to yeet it for ages. from the PR description:

on a small note, the FIXME on alias_term_kind_from_def_id becomes even more relevant with this PR, ty::AliasConstInherentArgsKind is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable.

(the FIXME reads // FIXME: remove in favor of explicit construction)

it's just, vaguely smelly and takes a chunk of refactoring effort to clean up the callsites, and nobody's bothered to do that yet. iirc it's mainly lowering, which, is a tangled mess that's been making my life very difficult whenever I've touched it for IAT stuff and whatnot. tl;dr it passes around Res/DefIds in a bunch of places where it really ought to be passing around AliasTerm or Term or whatever. Because it passes around DefId instead of AliasTerm, this alias_term_kind_from_def_id method is called. This lowering mess is the cause of #160844 among other things.

rustbot added PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 28, 2026

rustbot assigned BoxyUwU Aug 28, 2026

rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Aug 28, 2026

This comment has been minimized.

Sign in to view

khyperia force-pushed the explicitly-track-inherent-args branch from ebbc13d to 7d5a1c7 Compare August 30, 2026 14:39

BoxyUwU reviewed Aug 31, 2026

View reviewed changes

BoxyUwU approved these changes Aug 31, 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 Aug 31, 2026

explicitly track inherent const generic args kind

892c6bb

khyperia force-pushed the explicitly-track-inherent-args branch from 7d5a1c7 to 892c6bb Compare August 31, 2026 12:30

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 Aug 31, 2026

JonathanBrouwer mentioned this pull request Aug 31, 2026

Rollup of 4 pull requests #162081

Closed

JonathanBrouwer mentioned this pull request Aug 31, 2026

Rollup of 5 pull requests #162084

Closed

JonathanBrouwer mentioned this pull request Aug 31, 2026

Rollup of 10 pull requests #162087

Closed

GuillaumeGomez mentioned this pull request Aug 31, 2026

Rollup of 11 pull requests #162088

Closed

JonathanBrouwer mentioned this pull request Aug 31, 2026

Rollup of 12 pull requests #162089

Closed

jhpratt mentioned this pull request Sep 1, 2026

Rollup of 12 pull requests #162100

Closed

jhpratt mentioned this pull request Sep 1, 2026

Rollup of 11 pull requests #162101

Closed

JonathanBrouwer mentioned this pull request Sep 1, 2026

Rollup of 16 pull requests #162117

Merged

rust-bors Bot merged commit e7c0bd5 into rust-lang:main Sep 1, 2026
13 checks passed

rustbot added this to the 1.100.0 milestone Sep 1, 2026

lcnr reviewed Sep 1, 2026

View reviewed changes

khyperia deleted the explicitly-track-inherent-args branch September 1, 2026 17:15

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Aug 28, 2026

Uh oh!

This comment has been minimized.

khyperia commented Aug 28, 2026

Uh oh!

BoxyUwU Aug 31, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Aug 31, 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!

Uh oh!

Uh oh!

BoxyUwU Aug 31, 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!

Choose a reason for hiding this comment

Uh oh!

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!

BoxyUwU commented Aug 31, 2026

Uh oh!

BoxyUwU commented Aug 31, 2026

Uh oh!

rust-bors Bot commented Aug 31, 2026

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

khyperia commented Aug 28, 2026 •

edited by rustbot

Loading

BoxyUwU Aug 31, 2026 •

edited by rustbot

Loading

BoxyUwU Aug 31, 2026 •

edited by rustbot

Loading

BoxyUwU Aug 31, 2026 •

edited by rustbot

Loading

BoxyUwU left a comment •

edited by rustbot

Loading