Fix ICE on standard constants in type constraints (min_generic_const_args)

[sunny026]

This PR fixes an internal compiler error (ICE) where tcx.def_kind panics when attempting to resolve un-evaluated constant aliases whose parent definition is not a type const.

By adding explicit tcx.is_type_const(uv.def) guards to DefKind::AssocConst and DefKind::Const, and explicitly capturing DefKind::AnonConst | DefKind::Const { .. } | DefKind::AssocConst { .. } in the fallback block, we ensure that constants without the min_generic_const_args attribute are handled gracefully rather than triggering an unreachable panic.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @tiif (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, types
• compiler, types expanded to 73 candidates
• Random selection from 17 candidates

[Kivooeo]

Hey, thanks for a PR, few things:

• Is there a filled issue about this ICE? If so, please link this via adding Fixes <issue number> in your description
• Question about the guard you've added, it's a bit tricky and I'm not really confident in my knowledges about const stuff, but: doesn't if something is AssocConst implies that this is "const"? Because this check reads a little uneasy to me. Same for Const and AnonConst
• Can you please add a test, likely somewhere in tests/ui/consts maybe

View changes since this review

[sunny026]

Hey @Kivooeo, thanks for the review!

To answer your questions:

Issue number: There is no existing filled issue for this ICE. I ran into it naturally while experimenting with min_generic_const_args in type constraints. I can create an issue for tracking purposes if you'd prefer, but otherwise it's just a direct fix.

The is_type_const guard: You're completely right that AssocConst and Const imply they are constants. However, the tcx.is_type_const(uv.def) method isn't checking if it's a constant in general—it checks the specific is_type_const boolean field that lives inside the DefKind::AssocConst { is_type_const: bool } and DefKind::Const { is_type_const: bool } enum variants. We only want to apply this specific normalization path if the constant is actually being evaluated in a type context (i.e. as a generic const argument). If is_type_const is false, it's just a normal runtime constant, and passing it through the old logic was what caused the tcx.def_kind parent resolution to panic. The guard ensures we only capture actual type-level constants.

Adding a test: My latest commit actually blesses an existing test in tests/ui/const-generics/gca/ambiguous-on-failed-eval-with-vars-fail.rs. Before my fix, that test would ICE internally on the fallback, but now it correctly emits E0308: mismatched types instead of panicking! Do you think that test is sufficient since it exercises this exact code path, or would you still like me to add a dedicated, isolated test in tests/ui/consts?

[rustbot]

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.