Render pattern types nicely in mir dumps by oli-obk · Pull Request #136176 · rust-lang/rust

oli-obk · 2025-01-28T08:22:05Z

avoid falling through to the fallback rendering that just does a hex dump

best reviewed commit by commit

oli-obk · 2025-01-28T08:23:57Z

+ scope 1 {
+ debug x => const 2_u32 is 1..=;
+ scope 2 {
+ debug y => const 0_u32 is 1..=;


This one is fun. We do render as transmute for other things that are invalid (e.g. chars that aren't valid chars, or bools that aren't 0 or 1), but it's harder to do this here without running validation on it... and I'm not sure all the extra logic for doing so would be worth it.

compiler-errors

Would be nice if we had some way of statically validating that a ScalarInt is valid in a Layout for this exact check (and it may be useful elsewhere in the compiler).

But looks fine for now.

compiler-errors · 2025-01-28T15:35:11Z

r? compiler-errors @bors r+ rollup

bors · 2025-01-28T15:35:14Z

📌 Commit fd6713f has been approved by compiler-errors

It is now in the queue for this repository.

scottmcm · 2025-01-28T18:20:54Z

+fn main() {
+ // CHECK: debug x => const {transmute(0x00000002): (u32) is 1..=}
+ let x: pattern_type!(u32 is 1..) = unsafe { std::mem::transmute(2) };
+ // CHECK: debug y => const {transmute(0x00000000): (u32) is 1..=}


Hmm, definitely interesting. I guess this is falling under the "compilation doesn't have to detect UB" rule?

Well... we kinda do because there could be no UB, just const prop crossing a check that prevents UB. So this could happen in dead code. So there is an argument for showing that in pretty printing. I'll see if I can pull out the logic we use in const validation in a way that makes it reusable here

…ompiler-errors Render pattern types nicely in mir dumps avoid falling through to the fallback rendering that just does a hex dump r? `@scottmcm` best reviewed commit by commit

Rollup of 9 pull requests Successful merges: - rust-lang#136121 (Deduplicate operand creation between scalars, non-scalars and string patterns) - rust-lang#136134 (Fix SIMD codegen tests on LLVM 20) - rust-lang#136153 (Locate asan-odr-win with other sanitizer tests) - rust-lang#136161 (rustdoc: add nobuild typescript checking to our JS) - rust-lang#136166 (interpret: is_alloc_live: check global allocs last) - rust-lang#136168 (GCI: Don't try to eval / collect mono items inside overly generic free const items) - rust-lang#136170 (Reject unsound toggling of Arm atomics-32 target feature) - rust-lang#136176 (Render pattern types nicely in mir dumps) - rust-lang#136186 (uefi: process: Fix args) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#136176 - oli-obk:pattern-type-mir-opts, r=compiler-errors Render pattern types nicely in mir dumps avoid falling through to the fallback rendering that just does a hex dump r? ``@scottmcm`` best reviewed commit by commit

Pretty print pattern type values with transmute if they don't satisfy their pattern Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`. These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code. follow-up to rust-lang#136176 cc `@compiler-errors` `@scottmcm` r? `@RalfJung` because of the interpreter changes

Pretty print pattern type values with transmute if they don't satisfy their pattern Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`. These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code. follow-up to rust-lang#136176 cc ``@compiler-errors`` ``@scottmcm`` r? ``@RalfJung`` because of the interpreter changes

Pretty print pattern type values with transmute if they don't satisfy their pattern Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`. These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code. follow-up to rust-lang#136176 cc ```@compiler-errors``` ```@scottmcm``` r? ```@RalfJung``` because of the interpreter changes

Pretty print pattern type values with transmute if they don't satisfy their pattern Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`. These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code. follow-up to rust-lang#136176 cc `@compiler-errors` `@scottmcm` r? `@RalfJung` because of the interpreter changes

Pretty print pattern type values with transmute if they don't satisfy their pattern Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`. These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code. follow-up to rust-lang#136176 cc ``@compiler-errors`` ``@scottmcm`` r? ``@RalfJung`` because of the interpreter changes

Rollup merge of rust-lang#136235 - oli-obk:transmuty-pat-tys, r=RalfJung Pretty print pattern type values with transmute if they don't satisfy their pattern Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`. These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code. follow-up to rust-lang#136176 cc ``@compiler-errors`` ``@scottmcm`` r? ``@RalfJung`` because of the interpreter changes

Pretty print pattern type values with transmute if they don't satisfy their pattern Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`. These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code. follow-up to rust-lang/rust#136176 cc ``@compiler-errors`` ``@scottmcm`` r? ``@RalfJung`` because of the interpreter changes

Rollup of 9 pull requests Successful merges: - rust-lang#136121 (Deduplicate operand creation between scalars, non-scalars and string patterns) - rust-lang#136134 (Fix SIMD codegen tests on LLVM 20) - rust-lang#136153 (Locate asan-odr-win with other sanitizer tests) - rust-lang#136161 (rustdoc: add nobuild typescript checking to our JS) - rust-lang#136166 (interpret: is_alloc_live: check global allocs last) - rust-lang#136168 (GCI: Don't try to eval / collect mono items inside overly generic free const items) - rust-lang#136170 (Reject unsound toggling of Arm atomics-32 target feature) - rust-lang#136176 (Render pattern types nicely in mir dumps) - rust-lang#136186 (uefi: process: Fix args) r? `@ghost` `@rustbot` modify labels: rollup

oli-obk added 2 commits January 28, 2025 08:12

Add mir-opt pattern type tests
7877d86

Make mir dumps more readable
fd6713f

rustbot assigned scottmcm Jan 28, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 28, 2025

oli-obk commented Jan 28, 2025
View reviewed changes

compiler-errors approved these changes Jan 28, 2025
View reviewed changes

rustbot assigned compiler-errors and unassigned scottmcm Jan 28, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 28, 2025

scottmcm reviewed Jan 28, 2025
View reviewed changes

Zalathar mentioned this pull request Jan 29, 2025
Rollup of 8 pull requests #136222
Closed

fmease mentioned this pull request Jan 29, 2025
Rollup of 9 pull requests #136227
Merged

oli-obk mentioned this pull request Jan 29, 2025
Pretty print pattern type values with transmute if they don't satisfy their pattern #136235
Merged

bors merged commit f49ad60 into rust-lang:masterJan 29, 2025

rustbot added this to the 1.86.0 milestone Jan 29, 2025

Navigation Menu

Uh oh!

Uh oh!

Render pattern types nicely in mir dumps - #136176

Render pattern types nicely in mir dumps#136176
bors merged 2 commits into
rust-lang:masterfrom
oli-obk:pattern-type-mir-opts

oli-obk commented Jan 28, 2025

Uh oh!

oli-obkJan 28, 2025•
edited
Loading

Uh oh!

compiler-errors left a comment

Uh oh!

compiler-errors commented Jan 28, 2025

Uh oh!

bors commented Jan 28, 2025

Uh oh!

scottmcmJan 28, 2025

Uh oh!

oli-obkJan 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

oli-obk commented Jan 28, 2025

Uh oh!

oli-obkJan 28, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

compiler-errors left a comment

Choose a reason for hiding this comment

Uh oh!

compiler-errors commented Jan 28, 2025

Uh oh!

bors commented Jan 28, 2025

Uh oh!

scottmcmJan 28, 2025

Choose a reason for hiding this comment

Uh oh!

oli-obkJan 28, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

oli-obkJan 28, 2025•
edited
Loading