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

JonathanBrouwer · 2026-05-05T19:21:39Z

No worries, these things happen, especially with soft conflicts there's really nothing you can do about them <3

@BoxyUwU

generic_const_args: allow paths to non type consts tracking issue: rust-lang#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. rust-lang#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

rust-bors · 2026-05-05T22:56:17Z

⌛ Testing commit cb2c5fc with merge e8140f1...

Workflow: https://github.com/rust-lang/rust/actions/runs/25406820612

@BoxyUwU

generic_const_args: allow paths to non type consts 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

@BoxyUwU

generic_const_args: allow paths to non type consts tracking issue: rust-lang#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. rust-lang#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

jhpratt · 2026-05-05T23:01:51Z

For encompassing rollup

@bors yield

rust-bors · 2026-05-05T23:01:54Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/25406820612

The next pull request likely to be tested is #156213.

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

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

@BoxyUwU

Rollup merge of #155341 - khyperia:non-type-const, r=BoxyUwU generic_const_args: allow paths to non type consts 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

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

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 53e96d1Compare April 16, 2026 06:38

khyperia force-pushed the non-type-const branch from 53e96d1 to bc46b88Compare 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 1103290Compare 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 threadcompiler/rustc_next_trait_solver/src/solve/normalizes_to/anon_const.rs Outdated
Comment threadcompiler/rustc_next_trait_solver/src/solve/eval_ctxt/mod.rs Outdated
Comment threadcompiler/rustc_trait_selection/src/traits/project.rs Outdated

khyperia commented Apr 24, 2026
View reviewed changes

Comment threadcompiler/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 556ad2fCompare 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 a34e848Compare 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 16ab434Compare May 1, 2026 16:32

rust-borsBot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label May 5, 2026

jhpratt mentioned this pull request May 5, 2026
Rollup of 12 pull requests #156207
Closed

jhpratt mentioned this pull request May 5, 2026
Rollup of 12 pull requests #156213
Closed

jhpratt mentioned this pull request May 6, 2026
Rollup of 15 pull requests #156217
Merged

rust-borsBot merged commit b2cc990 into rust-lang:mainMay 6, 2026
11 of 12 checks passed

rustbot added this to the 1.97.0 milestone May 6, 2026

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

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

khyperiaApr 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!

BoxyUwUApr 27, 2026

Choose a reason for hiding this comment

Uh oh!

khyperiaApr 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!

BoxyUwUMay 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!

JonathanBrouwer commented May 5, 2026

Uh oh!

rust-borsBot commented May 5, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jhpratt commented May 5, 2026

Uh oh!

rust-borsBot commented May 5, 2026

Uh oh!

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

khyperiaApr 22, 2026•
edited by rustbot
Loading

BoxyUwU left a comment •
edited by rustbot
Loading

BoxyUwU left a comment •
edited by rustbot
Loading

rust-borsBot commented May 5, 2026•
edited
Loading