generic_const_args: allow paths to non type consts by khyperia · Pull Request #155341 · rust-lang/rust

khyperia · 2026-04-15T13:16:06Z

tracking issue: #151972

Non type consts should be usable in the type system in feature(generic_const_args). These are directly plugged into the constant evaluator, unlike type consts, which are attempted to be reasoned about by the type system.

Inherent associated constants are not supported at this time, due to complications around how generic arguments are represented for them (it's currently a mess). The mess is being cleaned up (e.g. #154758), so instead of trying to hack support in before the refactoring is done, let's just wait to be able to implement it more cleanly.

r? @BoxyUwU

rustbot · 2026-04-15T13:16:10Z

changes to the core type system

cc @lcnr

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred in engine.rs, potentially modifying the public API of ObligationCtxt.

cc @lcnr

Some changes occurred in const_evaluatable.rs

cc @BoxyUwU

HIR ty lowering was modified

cc @fmease

changes to the core type system

cc @lcnr

BoxyUwU

cool ✨ two big picture things:

you've changed evaluate_const to take an unevaluated const instead of a ty::Const. iirc we talked about doing this to make IACs work but since we've dropped support for them can those changes be reverted?
if it would be kinda chill for you to do can you make the change of adding fields to AliasTermKind's variants be in a separate commit so it's easier to review just the "meaningful" stuff? If it's non-trivial/difficult it's fine to keep it as is 🤔

View changes since this review

khyperia · 2026-04-16T06:42:05Z

you've changed evaluate_const to take an unevaluated const instead of a ty::Const. iirc we talked about doing this to make IACs work but since we've dropped support for them can those changes be reverted?

yeah I guess, it just makes me sad to revert, the change seems nice :c :P - I've stashed the work so can maybe done sometime in the future

if it would be kinda chill for you to do can you make the change of adding fields to AliasTermKind's variants be in a separate commit so it's easier to review just the "meaningful" stuff? If it's non-trivial/difficult it's fine to keep it as is 🤔

done!

edit: ack, the split wasn't fully clean, there's a swap from is_type to pattern matching in the first commit that should be in the second commit, in normalize.rs, sowwy

edit: ok, pushed, moving the change to the other commit

cc @WaffleLapkin when AliasTermKind has been updated to store DefIds like you've done for AliasTyKind this can be removed and we can just call tcx.is_type_const(def) everywhere instead

I think the DefId is already available in all the relevant places - I don't think adding a is_type_const field is strictly necessary, I just thought it was cleaner/nicer, especially with the exhaustive pattern matching nice things. Totally reasonable for me to use tcx.is_type_const though, let me know what style you'd prefer!

BoxyUwU

I'm not super fussy about the is_type_const field I guess. It probably doesn't really change much about how much effort it'll be for one of you or waffle to fix things up between this and #155392.

I think this PR basically just needs some more tests at this point. I'm thinking off the top of my head.

generic uses of free consts, e.g. FREE<N> so it can't just be immediately evaluated
equality rules of non-type consts, so for both free and associated consts we should have tests that:
- ALIAS1 and ALIAS2 are equal if they evalaute to the same value (and aren't if they don't).
- ALIAS<N> is only equal to itself and not other aliases with the same body

then it should be good to go

View changes since this review

BoxyUwU · 2026-04-20T13:42:53Z

oh also can you link to the tracking issue for gca in the PR description

khyperia · 2026-04-22T18:40:45Z

+                    // Perhaps we could split EvaluateConstErr::HasGenericsOrInfers into HasGenerics
+                    // and HasInfers or something, and make evaluate_const_and_instantiate change
+                    // its behavior based on that, rather than it checking `has_non_region_infer`.
+                    let target_args = ecx.resolve_vars_if_possible(target_args);


@BoxyUwU this is annoying and gross (see HACK comment), resolve_vars_if_possible is called twice on target_args. I could maybe clean this up in a follow-up PR? Or I could gut/refactor in this PR. I would slightly prefer doing it in a follow-up, but, let me know!

View changes since the review

we probably should split EvaluateConstErr in two eventually yeah.

Can you move this resolve_vars_if_possible into evaluate_const_and_instantiate_normalizes_to_term. Right now it kind of detracts from understanding the high level logic of how normalization works

BoxyUwU

thx this looks good ✨

View changes since this review

rustbot · 2026-05-01T10:55:19Z

The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes.

cc @BoxyUwU, @tshepang

BoxyUwU

do we have a test which would expose the "normalizing free alias to an infer var resulting in MIR typeck ICEs"? would be nice to add that revisioned on both old/new solver so we can show new solver working and if we allow GCA with old solver we know it also works

View changes since this review

BoxyUwU · 2026-05-01T11:52:24Z

+        return;
+    }
+
+    // Require the new solver with GCA, because the old solver does not implement GCA correctly.


Suggested change

// Require the new solver with GCA, because the old solver does not implement GCA correctly.

// Require the new solver with GCA, because the old solver can't implement GCA correctly

// as it does not support normalization obligations for free and inherent consts.

khyperia · 2026-05-01T13:38:44Z

do we have a test which would expose the "normalizing free alias to an infer var resulting in MIR typeck ICEs"?

Yes, tests/ui/const-generics/gca/ambiguous-on-failed-eval-with-vars-fail.rs is that test (specifically the test_free_mismatch function). That test used to ICE on the old solver and is the source of what we talked about of disabling the old solver on gca ✨

would be nice to add that revisioned on both old/new solver so we can show new solver working and if we allow GCA with old solver we know it also works

what do you mean by that? like, add a .old.stderr bless that's just, error: generic_const_exprs requires -Znext-solver=globally to be enabled?

BoxyUwU · 2026-05-01T13:46:12Z

like, add a .old.stderr bless that's just, error: generic_const_exprs requires -Znext-solver=globally to be enabled?

yeah, that way it'll change from that to incorrectly passing or something if we allow the feature in the old solver

Rollup of 15 pull requests Successful merges: - rust-lang/rust#151122 (fix: more descriptive error message for enum to integer) - rust-lang/rust#155341 (generic_const_args: allow paths to non type consts) - rust-lang/rust#156062 (Added command-line argument support for `wasm32-wali-linux-musl`) - rust-lang/rust#156159 ([AIX] add -bdbg:namedsects:ss link arg) - rust-lang/rust#156174 (Wasm: remove implicit `__heap_base`/`__data_end` exports) - rust-lang/rust#156186 (fix: remap ci-llvm debug paths via `-ffile-prefix-map`) - rust-lang/rust#156193 (port `rustc_ast*` crates from `box_` to `deref_patterns`) - rust-lang/rust#156201 (Don't run ui-fulldeps tests twice in stage 1) - rust-lang/rust#155808 (Always use `ConstFn` context for `const` closures) - rust-lang/rust#156105 (interpret: correctly deal with repr(transparent) enums) - rust-lang/rust#156148 (Use `all_impls` instead of handrolling it) - rust-lang/rust#156156 (Adjust getMCSubtargetInfo signature for LLVM 23+) - rust-lang/rust#156170 (add known-bug test for coroutine 'static-yields-non-'static unsoundness (rust-lang/rust#144442)) - rust-lang/rust#156195 (Move tests codegen) - rust-lang/rust#156205 (move generalization test)

…oxyUwU Remove AnonConstKind::GCA and reject generic anon consts Previously, a `GCA` type const (`type const FOO<const N: usize>: usize = const { N + 1 };`) was a type-system-transparent type const whose body immediately thunked out to an opaque regular const (albeit an anon const). The fact that there was a transparent wrapper wasn't providing anything of value, now that the user can write and rust-lang#155341. With this PR, `GCA` variant is removed from `AnonConstKind` so that generic anon consts are rejected. Related: rust-lang/project-const-generics#113

Rollup merge of #157773 - LaneAsade:generic_anon_consts, r=BoxyUwU Remove AnonConstKind::GCA and reject generic anon consts Previously, a `GCA` type const (`type const FOO<const N: usize>: usize = const { N + 1 };`) was a type-system-transparent type const whose body immediately thunked out to an opaque regular const (albeit an anon const). The fact that there was a transparent wrapper wasn't providing anything of value, now that the user can write and #155341. With this PR, `GCA` variant is removed from `AnonConstKind` so that generic anon consts are rejected. Related: rust-lang/project-const-generics#113

@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

@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

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

@BoxyUwU

…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/rust#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/rust#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/rust#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

…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/rust#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/rust#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/rust#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

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Apr 15, 2026

rustbot assigned BoxyUwU Apr 15, 2026

BoxyUwU reviewed Apr 15, 2026

View reviewed changes

khyperia force-pushed the non-type-const branch from cd8a2ae to 53e96d1 Compare April 16, 2026 06:38

khyperia force-pushed the non-type-const branch from 53e96d1 to bc46b88 Compare April 16, 2026 06:52

This comment has been minimized.

Sign in to view

BoxyUwU reviewed Apr 20, 2026

View reviewed changes

khyperia force-pushed the non-type-const branch from bc46b88 to 1103290 Compare April 22, 2026 18:30

This comment has been minimized.

Sign in to view

khyperia commented Apr 22, 2026

View reviewed changes

BoxyUwU reviewed Apr 24, 2026

View reviewed changes

Comment thread compiler/rustc_next_trait_solver/src/solve/normalizes_to/anon_const.rs Outdated

Comment thread compiler/rustc_next_trait_solver/src/solve/eval_ctxt/mod.rs Outdated

Comment thread compiler/rustc_trait_selection/src/traits/project.rs Outdated

khyperia commented Apr 24, 2026

View reviewed changes

Comment thread compiler/rustc_next_trait_solver/src/solve/eval_ctxt/mod.rs

khyperia force-pushed the non-type-const branch 4 times, most recently from ce2009d to 556ad2f Compare May 1, 2026 10:55

This comment has been minimized.

Sign in to view

BoxyUwU reviewed May 1, 2026

View reviewed changes

khyperia force-pushed the non-type-const branch from 556ad2f to a34e848 Compare May 1, 2026 16:17

rustbot added the A-rustc-dev-guide Area: rustc-dev-guide label May 1, 2026

khyperia force-pushed the non-type-const branch 2 times, most recently from 10217a1 to 16ab434 Compare May 1, 2026 16:32

matthiaskrgr mentioned this pull request May 7, 2026

[ICE]: symbol_names: unsupported constant of type #156294

Closed

khyperia deleted the non-type-const branch May 15, 2026 06:58

josetorrs mentioned this pull request May 15, 2026

refactor TypeRelativePath::AssocItem to use AliasTerm #155323

Merged

1 task

khyperia mentioned this pull request Jun 9, 2026

Remove AnonConstKind::GCA and reject generic anon consts #157651

Closed

LaneAsade mentioned this pull request Jun 11, 2026

Remove AnonConstKind::GCA and reject generic anon consts #157773

Merged

khyperia mentioned this pull request Aug 28, 2026

explicitly track inherent const generic args kind #161929

Merged

	// Require the new solver with GCA, because the old solver does not implement GCA correctly.
	// Require the new solver with GCA, because the old solver can't implement GCA correctly
	// as it does not support normalization obligations for free and inherent consts.

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Apr 15, 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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

khyperia commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

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 Apr 20, 2026

Uh oh!

This comment has been minimized.

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

khyperia Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented May 1, 2026

Uh oh!

This comment has been minimized.

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!

Uh oh!

BoxyUwU May 1, 2026

Choose a reason for hiding this comment

Uh oh!

khyperia commented May 1, 2026

Uh oh!

BoxyUwU commented May 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

khyperia commented Apr 15, 2026 •

edited by rustbot

Loading

BoxyUwU left a comment •

edited by rustbot

Loading

khyperia commented Apr 16, 2026 •

edited

Loading

BoxyUwU left a comment •

edited by rustbot

Loading

khyperia Apr 22, 2026 •

edited by rustbot

Loading

BoxyUwU left a comment •

edited by rustbot

Loading

BoxyUwU left a comment •

edited by rustbot

Loading