Allow int literals for pattern types with int base types #137715
Conversation
rustbot
added
S-waiting-on-review
|
changes to the core type system HIR ty lowering was modified cc @fmease changes to the core type system Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
oli-obk
force-pushed
the
pattern-type-literals
branch
2 times, most recently
from
2845be6 to
897ace8
Compare
This comment was marked as resolved.
This comment was marked as resolved.
oli-obk
force-pushed
the
pattern-type-literals
branch
2 times, most recently
from
e5f8770 to
e9f5d48
Compare
| if layout.uninhabited { | ||
| None | ||
| } else { |
There was a problem hiding this comment.
Patterns types of integers cant be uninhabited can they?
There was a problem hiding this comment.
even if they were why would we want to fallback to an integer var instead of using the expected (uninhabited) pattern type
There was a problem hiding this comment.
I don't know if u32 is 10..2 exists, but if it does then it's uninhabited.
(And it might be nice to just allow the type to exist so that we don't need where {MIN <= MAX} bounds on things.)
There was a problem hiding this comment.
This PR makes us error when encountering wrapping ranges like 10..2 so that wouldn't be uninhabited as of this PR. Though if it did exist I could imagine it being uninhabited
There was a problem hiding this comment.
oops yea that was just a leftover from doing various pattern types things in parallel. I turned it into an assert
BoxyUwU
added
S-waiting-on-author
| fn negative_lit_in_range() -> pattern_type!(i8 is -5..5) { | ||
| -2 | ||
| //~^ ERROR: cannot apply unary operator `-` to type `(i8) is -5..=4` | ||
| } |
There was a problem hiding this comment.
Is this something you expect to start supporting with your other work about having negated literals explicit in the ast/hir?
There was a problem hiding this comment.
Yes, that's why I started that work
oli-obk
force-pushed
the
pattern-type-literals
branch
from
e9f5d48 to
f87e58f
Compare
oli-obk
added
S-waiting-on-review
r? @BoxyUwU
I also added an error at layout computation time for layouts that contain wrapping ranges (happens at monomorphization time). This is obviously hacky, but at least prevents such types from making it to codegen for now. It made writing the tests for int literals easier as I didn't have to think about that edge case
Basically this PR allows you to stop using transmutes for creating pattern types and instead just use literals:
works, and if the literal is out of range you get a type mismatch because it just stays at the base type and the base type can't be coerced to the pattern type.
cc @joshtriplett @scottmcm