Patterns: represent constants as valtrees#144591
Conversation
|
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
|
Some changes occurred in cc @BoxyUwU Some changes occurred in match lowering cc @Nadrieril Some changes occurred in exhaustiveness checking cc @Nadrieril Some changes occurred in match checking cc @Nadrieril |
|
|
||
| let mut expect_ty = value.ty(); | ||
| let mut expect_ty = value_ty; | ||
| let value = Const::Ty(value_ty, ty::Const::new_value(tcx, value, value_ty)); |
There was a problem hiding this comment.
Oddly, constructing a mir::Const from a valtree requires the type twice...
There was a problem hiding this comment.
Const::Ty storing more than just a ty::Const is kinda meh yeah. This came about when we stopped storing a Ty alongside all ty::Consts. Removing the ty field from Const::Ty would require updating the function mir::Const::ty( to take either a TypingEnv so we can lookup the type of const parameters, and so that we can normalize the resulting type from type_of unevaluated constants and const generic parameter declarations
There was a problem hiding this comment.
It is odd that mir::Const and ty::Value know their type but ty::Const does not... but I won't touch this now, there's probably a reason we ended up here.^^
There was a problem hiding this comment.
you can likely find a bit of context in #125958 as to how ty::Const wound up the way it did. For ty::Const only ty::Value needs a Ty because everything else we can "figure out" the type from the environment we're in or from the ty::Const itself.
I would expect that mir::Const::Unevaluated doesnt really need to store a Ty either as it should just be equivalent to type_of(uv.def).instantiate(uv.args) and then a normalization call 🤔
| let max = ty.numeric_max_val(cx.tcx).unwrap(); | ||
| let max = ty::ValTree::from_scalar_int(cx.tcx, max.try_to_scalar_int().unwrap()); |
There was a problem hiding this comment.
This is a kind of silly dance. Maybe numeric_max_val should just return a ScalarInt?
ee610cc to
b39c019
Compare
|
@rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Patterns: represent constants as valtrees
This comment has been minimized.
This comment has been minimized.
Given that we evaluate all const patterns by going through a Regardless, with this in mind I think using |
|
Finished benchmarking commit (e111586): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary -0.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -3.3%, secondary 2.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 468.526s -> 467.78s (-0.16%) |
52c6e8f to
1870bd2
Compare
| type Error = ErrorGuaranteed; | ||
| type VariantIdx = VariantIdx; | ||
| type StrLit = Const<'tcx>; | ||
| type StrLit = ty::Value<'tcx>; |
There was a problem hiding this comment.
Oddly it seems like I can just change this type and nobody cares...
| Success, | ||
| /// Branch corresponding to this constant. | ||
| Constant(Const<'tcx>, u128), | ||
| Constant(ty::Value<'tcx>, u128), |
There was a problem hiding this comment.
This is the one place where dropping the type and just using a ValTree would work... but for consistency I kept it here, too.
|
@bors try |
This comment has been minimized.
This comment has been minimized.
Patterns: represent constants as valtrees
Co-authored-by: Boxy <rust@boxyuwu.dev>
eacd56a to
2330afa
Compare
|
@rustbot ready |
|
@bors r+ rollup=never I don't know why the perf regression is there 🤔 I have to assume its just noise from boring code movement changes. |
|
ah actually @RalfJung can you update the PR description? its a bit out of date now as we're using |
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 3507a74 (parent) -> 8800ec1 (this PR) Test differencesShow 2 test diffs2 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 8800ec16657b24ad8a2f443c133bf0b56ae76033 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (8800ec1): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 2.0%, secondary -1.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 4.8%, secondary -1.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.5%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 469.244s -> 470.592s (0.29%) |
|
That clap_derive regression is new (didn't show up in the prior bench runs here)... but that benchmark seems to have fluctuated with the last few PRs so I assume it is spurious. |
|
Yes, it's indeed noise. @rustbot label: +perf-regression-triaged |
|
The match-stress regression seems real, but probably not important to look into given the context of this PR. |
|
I tried various things in this PR to avoid it and nothing helped 🤷 . |
|
Oh yay, constants is one of the uglier parts of handling patterns, this is a nice improvement. |
Const patterns are always valtrees now. Let's represent that in the types. We use
ty::Valuefor this since it nicely packages value and type, and has some convenient methods.Cc @Nadrieril @BoxyUwU