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

rustbot · 2026-04-22T18:30:30Z

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-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:49:53Z

+                    // - the fresh vars are then used as target_args
+                    // we need the actual args to run const eval, so we need to actually do the `eq`
+                    // and figure out the args, so, call try_evaluate_added_goals
+                    ecx.try_evaluate_added_goals()?;


do you have a link to a test that requires this?

I'm wondering if it make sense to move this into evaluate_const_and_instantiate_normalizes_to_term. I don't think evaluating free consts would need this but I expect IACs will wind up needing it too. And generally it just feels kind of more principled to do so 🤔/would make the code nicer to read I think.

I could have sworn this was necessary in an earlier version of the code, but I can't for the life of me get a repro where it's necessary now. Perhaps it was only necessary with IACs, but not with projected.

I'm unable to find a repro with this line commented out:

rust/compiler/rustc_next_trait_solver/src/solve/normalizes_to/mod.rs

Line 255 in 0469a92

ecx.try_evaluate_added_goals()?;

but that line already does what the line in my PR is attempting to do, so I think it's fine to delete this line from my PR.

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

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

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 from a34e848 to 10217a1 Compare May 1, 2026 16:21

generic_const_args: allow paths to non type consts

16ab434

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

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

rustbot commented Apr 22, 2026

Uh oh!

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!

BoxyUwU May 1, 2026

Choose a reason for hiding this comment

Uh oh!

khyperia May 1, 2026

Choose a reason for hiding this comment

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!

4 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