-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split thir::PatKind::ExpandedConstant
into two distinct kinds
#136529
base: master
Are you sure you want to change the base?
Conversation
These two kinds of marker node are superficially similar, but are actually very different in practice, and there is no code that actually wants to treat them as the same thing.
Some changes occurred in match checking cc @Nadrieril Some changes occurred in exhaustiveness checking cc @Nadrieril |
The commonality between them is that they both correspond to "this was a const turned into a pattern". This has semantic meaning in a way that splitting it in two variants doesn't imo. E.g. if we added a new way to have a const turn into a pattern I'd want us to keep using Said differently, I feel like the small gain at the two use sites comes at the cost of every consumer of THIR having to wonder if they should handle these two differently. |
That's the theory, but in practice there are zero places that make use of that semantic meaning. Currently I don't think it's even possible for code to care about that meaning, because the two kinds of “expanded constant” are handled inconsistently (e.g. by range patterns, which retain inline-const markers but discard named-const markers).
The gain is that I couldn't figure out what ExpandedConstant was supposed to mean, until I realised that it was two completely unrelated things that had been squished into a single PatKind because they both happen to involve “constants” and have similarly-named fields. And right now every consumer should handle them differently (and does handle them differently), because they mean and do totally different things. If you really think it's right for them to be the same, I'm open to ideas for how to make them less confusing and inconsistent. But I really don't like the current situation, where they are pretending to be the same in a way that only makes both of them harder to deal with. |
E.g. another plan might be:
I didn't take that approach in this PR because I assumed that separating them is simpler, but it would still be an improvement IMO. |
The fact that you were confused is a strong point.
Tbf that's expected, because this shouldn't make a semantic difference. We only remember that info for diagnostic/unsafe-checking purposes. The plan you propose is basically how I was thinking about it. I do see that propagating For context imo mixing diagnostics-related code and semantics-related code is a big source of the technical debt we have in the compiler today. Hence my preference for not doing that, which is why I argued for merging these two variants when they were introduced. What was confusing about My ideal state would be that we do unsafeck pre-THIR so we don't have to do this weird hack around range patterns, and we keep |
Thanks, I think I understand the situation a bit more now. I'll have a think about what the docs could say to make things clearer. |
This comment was marked as outdated.
This comment was marked as outdated.
…-errors mir_build: Clarify some code for lowering `hir::PatExpr` to THIR A few loosely-related improvements to the code that lowers certain parts of HIR patterns to THIR. I was originally deferring this until after rust-lang#136529, but that PR probably won't happen, whereas these changes should hopefully be uncontroversial. r? Nadrieril or reroll
…-errors mir_build: Clarify some code for lowering `hir::PatExpr` to THIR A few loosely-related improvements to the code that lowers certain parts of HIR patterns to THIR. I was originally deferring this until after rust-lang#136529, but that PR probably won't happen, whereas these changes should hopefully be uncontroversial. r? Nadrieril or reroll
Rollup merge of rust-lang#137028 - Zalathar:thir-pat-expr, r=compiler-errors mir_build: Clarify some code for lowering `hir::PatExpr` to THIR A few loosely-related improvements to the code that lowers certain parts of HIR patterns to THIR. I was originally deferring this until after rust-lang#136529, but that PR probably won't happen, whereas these changes should hopefully be uncontroversial. r? Nadrieril or reroll
These two kinds of marker node are superficially similar, but are actually very different in practice, and there is no code that actually wants to treat them as the same thing.
For historical reference,
PatKind::InlineConst
was introduced in #116482 to fix THIR unsafeck for inline-const blocks in range pattern endpoints.It was then modified by #132708 (and renamed to
PatKind::ExpandedConstant
) to also mark named constants, for a diagnostic improvement for code that accidentally tries to perform an irrefutable binding to a name that is already used by a constant. The two sub-variants were indicated by a boolean field, which also changed the significance of thedef_id
field.But tellingly, there was no code that actually wanted to equivocate between the two. Every occurrence was specifically interested in inline-const, or specifically interested in named-const, or was simply trying to traverse/unpeel pattern nodes without regard for their meaning.