avoid ICE when generics sneak into a constant pattern#159504
Conversation
|
Some changes occurred in match checking cc @Nadrieril |
|
|
| // become necessary to just use type system normalization for all const patterns | ||
| // but that's not yet possible. | ||
| let mut thir_pat = if alias_const.kind.is_type_const(self.tcx) { | ||
| let const_value = if alias_const.kind.is_type_const(self.tcx) { |
There was a problem hiding this comment.
It seems kind of odd to me that we are treating type constants separately here, I would think there should be a uniform code path... but that is pre-existing so 🤷
|
I think this PR doesn't change anything at all. If there's a breaking change it already occurred when #156977 landed which made it so that evaluating a constant with generics in its type can never get past validation. Maybe we should just have that check in the beginning of the query rather than the end, and make it a proper guarantee of our const-eval queries rather than something ad-hoc in const-to-pat? Cc @rust-lang/wg-const-eval |
That sounds a lot more principled, yes please |
Since recently, const validation has a
has_paramcheck, which means ConstToPat also implicitly has that check. But it seems better to check this again explicitly here rather then rely on an undocumented property of some other component. The new test behaves the same with or without the PR.I recommend hiding whitespace difference, since rustfmt re-indendet a bunch of stuff.
Fixes #150296
r? @BoxyUwU