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

@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.

rust-timer · 2026-09-01T18:43:47Z

Finished benchmarking commit (f26b04a): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	1
Improvements ✅ (secondary)	-0.4%	[-1.0%, -0.1%]	23
All ❌✅ (primary)	-0.1%	[-0.1%, -0.1%]	1

Max RSS (memory usage)

Results (secondary -2.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -4.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.5%	[-4.5%, -4.5%]	1
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: missing data
Artifact size: 400.59 MiB -> 401.27 MiB (0.17%)

matthiaskrgr · 2026-09-01T18:58:47Z

+                        // please ping khyperia and/or BoxyUwU if this `bug!` fires
+                        ty::AliasConstKind::InherentImpl { .. } => bug!(
+                            "This ought to be unreachable, the entrypoints of WF should still have InherentSelf-form alias consts."
+                        ),


reachable here:
#162146 (comment)

thank you, heckin' appreciate how quickly this got fuzzyhit and all the work you do here! (filed #162173 to fix this one, and #162168 for the other one)

matthiaskrgr · 2026-09-01T19:00:42Z

+            ty::AliasConstKind::InherentSelf { .. } => {
+                panic!(
+                    "AliasConst::type_of got InherentSelf - args should always be InherentImpl at this point"
+                )
+            }
+            ty::AliasConstKind::InherentImpl { def_id } => def_id.into(),


reachable here #162147 (comment)

khyperia · 2026-09-02T07:32:03Z

Overall result: ✅ improvements - no action needed

wait what the heck? uuuuh sure I guess, that's unexpected

fmease · 2026-09-02T07:44:42Z

Overall result: ✅ improvements - no action needed

wait what the heck? uuuuh sure I guess, that's unexpected

It seems like you're in invoking the def_kind query fewer times judging by the perf report. E.g.,

for projection-caching (opt, incr-full, llvm, x64):

Query/Function	Time (%)	Time (s)	Time delta	Executions	Executions delta	Hits	Hits delta	Incr. loading (s)	Incr. loading delta
def_kind	0.02%	0.000	-0.000 (-6.9%)	115	-10 (-8.0%)	44557	-113627 (-71.8%)	0.000	0.000 (0.0%)

for nalgebra-0.33.0 (check, incr-full, llvm, x64):

Query/Function	Time (%)	Time (s)	Time delta	Executions	Executions delta	Hits	Hits delta	Incr. loading (s)	Incr. loading delta
def_kind	0.12%	0.003	-0.000 (-0.3%)	1438	-89 (-5.8%)	2323681	-125239 (-5.1%)	0.000	0.000 (0.0%)

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix supposedly unreachable `bug!` being reachable `bug!` introduced in rust-lang#161929 fixes rust-lang#162146 wfcheck.rs does a normalize on a type here https://github.com/rust-lang/rust/blob/edc52f87c28f328c61685a02c47887a5cec7d767/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L929 which reduces the contained alias within from a nonrigid InherentSelf to a rigid InherentImpl, because we do so upon encountering a too-generic-to-ctfe alias the very next line, it then `register_wf_obligation` on the resulting normalized type, that contains an InherentImpl inside wf, that eventually hits the `bug!` I added and ICEs https://github.com/rust-lang/rust/blob/a4330234a776684c36428d001721d0320d24dd77/compiler/rustc_trait_selection/src/traits/wf.rs#L1104 r? @BoxyUwU

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

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix supposedly unreachable `bug!` being reachable `bug!` introduced in rust-lang#161929 fixes rust-lang#162146 wfcheck.rs does a normalize on a type here https://github.com/rust-lang/rust/blob/edc52f87c28f328c61685a02c47887a5cec7d767/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L929 which reduces the contained alias within from a nonrigid InherentSelf to a rigid InherentImpl, because we do so upon encountering a too-generic-to-ctfe alias the very next line, it then `register_wf_obligation` on the resulting normalized type, that contains an InherentImpl inside wf, that eventually hits the `bug!` I added and ICEs https://github.com/rust-lang/rust/blob/a4330234a776684c36428d001721d0320d24dd77/compiler/rustc_trait_selection/src/traits/wf.rs#L1104 r? @BoxyUwU

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

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix supposedly unreachable `bug!` being reachable `bug!` introduced in rust-lang#161929 fixes rust-lang#162146 wfcheck.rs does a normalize on a type here https://github.com/rust-lang/rust/blob/edc52f87c28f328c61685a02c47887a5cec7d767/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L929 which reduces the contained alias within from a nonrigid InherentSelf to a rigid InherentImpl, because we do so upon encountering a too-generic-to-ctfe alias the very next line, it then `register_wf_obligation` on the resulting normalized type, that contains an InherentImpl inside wf, that eventually hits the `bug!` I added and ICEs https://github.com/rust-lang/rust/blob/a4330234a776684c36428d001721d0320d24dd77/compiler/rustc_trait_selection/src/traits/wf.rs#L1104 r? @BoxyUwU

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix supposedly unreachable `bug!` being reachable `bug!` introduced in rust-lang#161929 fixes rust-lang#162146 wfcheck.rs does a normalize on a type here https://github.com/rust-lang/rust/blob/edc52f87c28f328c61685a02c47887a5cec7d767/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L929 which reduces the contained alias within from a nonrigid InherentSelf to a rigid InherentImpl, because we do so upon encountering a too-generic-to-ctfe alias the very next line, it then `register_wf_obligation` on the resulting normalized type, that contains an InherentImpl inside wf, that eventually hits the `bug!` I added and ICEs https://github.com/rust-lang/rust/blob/a4330234a776684c36428d001721d0320d24dd77/compiler/rustc_trait_selection/src/traits/wf.rs#L1104 r? @BoxyUwU

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix supposedly unreachable `bug!` being reachable `bug!` introduced in rust-lang#161929 fixes rust-lang#162146 wfcheck.rs does a normalize on a type here https://github.com/rust-lang/rust/blob/edc52f87c28f328c61685a02c47887a5cec7d767/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L929 which reduces the contained alias within from a nonrigid InherentSelf to a rigid InherentImpl, because we do so upon encountering a too-generic-to-ctfe alias the very next line, it then `register_wf_obligation` on the resulting normalized type, that contains an InherentImpl inside wf, that eventually hits the `bug!` I added and ICEs https://github.com/rust-lang/rust/blob/a4330234a776684c36428d001721d0320d24dd77/compiler/rustc_trait_selection/src/traits/wf.rs#L1104 r? @BoxyUwU

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

@BoxyUwU

fix supposedly unreachable `bug!` being reachable `bug!` introduced in rust-lang#161929 fixes rust-lang#162146 wfcheck.rs does a normalize on a type here https://github.com/rust-lang/rust/blob/edc52f87c28f328c61685a02c47887a5cec7d767/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L929 which reduces the contained alias within from a nonrigid InherentSelf to a rigid InherentImpl, because we do so upon encountering a too-generic-to-ctfe alias the very next line, it then `register_wf_obligation` on the resulting normalized type, that contains an InherentImpl inside wf, that eventually hits the `bug!` I added and ICEs https://github.com/rust-lang/rust/blob/a4330234a776684c36428d001721d0320d24dd77/compiler/rustc_trait_selection/src/traits/wf.rs#L1104 r? @BoxyUwU

@BoxyUwU

fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!

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

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

matthiaskrgr reviewed Sep 1, 2026

View reviewed changes

This was referenced Sep 2, 2026

fix ICE in project_goals/inherent #162168

Open

fix supposedly unreachable bug! being reachable #162173

Open

BoxyUwU mentioned this pull request Sep 3, 2026

Full Const Generics rust-lang/goals#100

Open

7 tasks

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!

rust-timer commented Sep 1, 2026

Overall result: ✅ improvements - no action needed

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!

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

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 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

fmease commented Sep 2, 2026 •

edited

Loading