mir_build: Classify TestableCase::Constant into multiple sub-kinds
#150238
Conversation
|
Some changes occurred in match lowering cc @Nadrieril |
rustbot
added
S-waiting-on-review
|
rustbot has assigned @jdonszelmann. Use |
Zalathar
force-pushed
the
pat-const-kind
branch
from
b5c6447 to
0e13a43
Compare
|
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. |
|
r? me |
|
Note that there’s currently a subtle distinction between the type of a pattern node, and the type of its constant value (if it’s a const pattern). I think it might be possible to eliminate that gap with some tweaks to how deref-patterns and pattern-type constants are lowered to THIR patterns, but I haven’t tried yet, and that’s well beyond the scope of this PR. (I'm looking into |
I think it's this thread: #project-deref-patterns > The string literal problem. |
|
I didn't mention this explicitly earlier, but my philosophy with this PR was to try to reflect the existing behaviour as much as possible. That produces results that are a bit weird/confusing, because the current behaviour is already a bit weird/confusing. I plan to do some follow-up work to try to improve things further, so this PR represents an intermediate stepping-stone, not a final result. |
Unlike the other types covered by `PatConstKind::Other`, const-float patterns can also interact with range patterns.
Zalathar
force-pushed
the
pat-const-kind
branch
from
0e13a43 to
1296925
Compare
|
New changes:
|
|
👍 finding this much clearer, ty! r=me when CI passes |
|
@bors r=Nadrieril |
bors
added
S-waiting-on-bors
mir_build: Classify `TestableCase::Constant` into multiple sub-kinds In match lowering, when choosing a test for a `TestableCase::Constant`, there is some ad-hoc logic for inspecting the pattern type and deciding what kind of test is suitable. There is also some very similar logic later, when partitioning cases into buckets based on the chosen test. Instead of having that ad-hoc logic in multiple places, I think it's better to perform an up-front classification when lowering `thir::PatKind::Constant` to `TestableCase::Constant`, and then have the later steps simply match on an enum variant. There should be no change to the resulting built MIR. (I will note that the logic/invariants involved are a bit unclear, so there is a risk of accidental minor differences.)
mir_build: Classify `TestableCase::Constant` into multiple sub-kinds In match lowering, when choosing a test for a `TestableCase::Constant`, there is some ad-hoc logic for inspecting the pattern type and deciding what kind of test is suitable. There is also some very similar logic later, when partitioning cases into buckets based on the chosen test. Instead of having that ad-hoc logic in multiple places, I think it's better to perform an up-front classification when lowering `thir::PatKind::Constant` to `TestableCase::Constant`, and then have the later steps simply match on an enum variant. There should be no change to the resulting built MIR. (I will note that the logic/invariants involved are a bit unclear, so there is a risk of accidental minor differences.)
Rollup merge of #150238 - Zalathar:pat-const-kind, r=Nadrieril mir_build: Classify `TestableCase::Constant` into multiple sub-kinds In match lowering, when choosing a test for a `TestableCase::Constant`, there is some ad-hoc logic for inspecting the pattern type and deciding what kind of test is suitable. There is also some very similar logic later, when partitioning cases into buckets based on the chosen test. Instead of having that ad-hoc logic in multiple places, I think it's better to perform an up-front classification when lowering `thir::PatKind::Constant` to `TestableCase::Constant`, and then have the later steps simply match on an enum variant. There should be no change to the resulting built MIR. (I will note that the logic/invariants involved are a bit unclear, so there is a risk of accidental minor differences.)
5 participants
In match lowering, when choosing a test for a
TestableCase::Constant, there is some ad-hoc logic for inspecting the pattern type and deciding what kind of test is suitable. There is also some very similar logic later, when partitioning cases into buckets based on the chosen test.Instead of having that ad-hoc logic in multiple places, I think it's better to perform an up-front classification when lowering
thir::PatKind::ConstanttoTestableCase::Constant, and then have the later steps simply match on an enum variant.There should be no change to the resulting built MIR.
(I will note that the logic/invariants involved are a bit unclear, so there is a risk of accidental minor differences.)