Skip to content
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

Allow int literals for pattern types with int base types #137715

Merged
merged 4 commits into from
Mar 12, 2025

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Feb 27, 2025

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:

let x: pattern_type!(u32 is 5..10) = 7;

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

@rustbot 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Feb 27, 2025
@rustbot
Copy link
Collaborator

rustbot commented Feb 27, 2025

changes to the core type system

cc @compiler-errors, @lcnr

HIR ty lowering was modified

cc @fmease

changes to the core type system

cc @compiler-errors, @lcnr

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@oli-obk oli-obk force-pushed the pattern-type-literals branch 2 times, most recently from 2845be6 to 897ace8 Compare March 5, 2025 09:11
@bors

This comment was marked as resolved.

@oli-obk oli-obk force-pushed the pattern-type-literals branch 2 times, most recently from e5f8770 to e9f5d48 Compare March 7, 2025 09:48
Comment on lines 1663 to 1665
if layout.uninhabited {
None
} else {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patterns types of integers cant be uninhabited can they?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

even if they were why would we want to fallback to an integer var instead of using the expected (uninhabited) pattern type

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops yea that was just a leftover from doing various pattern types things in parallel. I turned it into an assert

@BoxyUwU BoxyUwU added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 7, 2025
Comment on lines +26 to +29
fn negative_lit_in_range() -> pattern_type!(i8 is -5..5) {
-2
//~^ ERROR: cannot apply unary operator `-` to type `(i8) is -5..=4`
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something you expect to start supporting with your other work about having negated literals explicit in the ast/hir?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's why I started that work

@oli-obk oli-obk force-pushed the pattern-type-literals branch from e9f5d48 to f87e58f Compare March 10, 2025 09:37
@oli-obk oli-obk added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 10, 2025
@BoxyUwU
Copy link
Member

BoxyUwU commented Mar 11, 2025

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Mar 11, 2025

📌 Commit f87e58f has been approved by BoxyUwU

It is now in the queue for this repository.

@bors 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 Mar 11, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 11, 2025
…oxyUwU

Allow int literals for pattern types with int base types

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:

```rust
let x: pattern_type!(u32 is 5..10) = 7;
```

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`
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 11, 2025
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#137715 (Allow int literals for pattern types with int base types)
 - rust-lang#138002 (Disable CFI for weakly linked syscalls)
 - rust-lang#138051 (Add support for downloading GCC from CI)
 - rust-lang#138231 (Prevent ICE in autodiff validation by emitting user-friendly errors)
 - rust-lang#138245 (stabilize `ci_rustc_if_unchanged_logic` test for local environments)
 - rust-lang#138256 (Do not feed anon const a type that references generics that it does not have)
 - rust-lang#138284 (Do not write user type annotation for const param value path)
 - rust-lang#138296 (Remove `AdtFlags::IS_ANONYMOUS` and `Copy`/`Clone` condition for anonymous ADT)
 - rust-lang#138352 (miri native_calls: ensure we actually expose *mutable* provenance to the memory FFI can access)
 - rust-lang#138354 (remove redundant `body`  arguments)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 8a2e3ac into rust-lang:master Mar 12, 2025
6 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Mar 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants