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

@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

Rollup of 3 pull requests Successful merges: - #154861 (Add rlib digest to identify Rust object files) - #155341 (generic_const_args: allow paths to non type consts) - #156014 (resolve: Catch "cannot reexport" errors from macros 2.0 better)

@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

JonathanBrouwer · 2026-05-05T12:24:56Z

@bors r-
#156179 (comment)

rust-bors · 2026-05-05T12:25:03Z

This pull request was unapproved.

This PR was contained in the following rollups:

Rollup of 3 pull requests #156179 was unapproved
Rollup of 7 pull requests #156189 was unapproved

View changes since this unapproval

rustbot · 2026-05-05T15:35:33Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

khyperia · 2026-05-05T19:20:08Z

apologies, @JonathanBrouwer !

boxy re-reviewed with me in zulip dms (the rollup failure was due to a merge conflict with #155543 which was merged only a few hours ago, which I now rebased to latest main again and fixed), so:

@bors r=BoxyUwU

rust-bors · 2026-05-05T19:20:14Z

📌 Commit cb2c5fc has been approved by BoxyUwU

It is now in the queue for this repository.

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)

@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

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)

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

rust-bors Bot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 5, 2026

jhpratt mentioned this pull request May 5, 2026

Rollup of 3 pull requests #156179

Closed

GuillaumeGomez mentioned this pull request May 5, 2026

Rollup of 7 pull requests #156189

Closed

rust-bors Bot 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 5, 2026

generic_const_args: allow paths to non type consts

cb2c5fc

khyperia force-pushed the non-type-const branch from c89c812 to cb2c5fc Compare May 5, 2026 15:35

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

Open

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

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!

JonathanBrouwer commented May 5, 2026

Uh oh!

rust-bors Bot commented May 5, 2026

Uh oh!

rustbot commented May 5, 2026

Uh oh!

khyperia commented May 5, 2026

Uh oh!

rust-bors Bot commented May 5, 2026

Uh oh!

JonathanBrouwer commented May 5, 2026

Uh oh!

rust-bors Bot 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-bors Bot commented May 5, 2026

Uh oh!

Reviewers

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

rust-bors Bot commented May 5, 2026 •

edited

Loading