-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Start using pattern types in libcore #136006
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
base: master
Are you sure you want to change the base?
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment has been minimized.
This comment has been minimized.
e3e2cbd to
ff4d569
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well r=me when/if it does get unblocked.
This comment has been minimized.
This comment has been minimized.
library/core/src/num/niche_types.rs
Outdated
| #[repr(transparent)] | ||
| $(#[$m])* | ||
| #[cfg(not(bootstrap))] | ||
| $vis struct $name(pattern_type!($int is $low..=$high)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsure: at least for the NonZeroBlahInner ones, it'd be nicer if these could just be type $name = pattern_type!($int is $low..=$high);, without the extra wrapper. Is that feasible, or are the trait implementations too far off?
(Relatedly, I'd love to be able to just derive traits on these again, particularly to not have to manually StructuralPartialEq.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea... I wanna get there, but directly using pattern types is not a great experience at present
ff4d569 to
0409353
Compare
This comment has been minimized.
This comment has been minimized.
0409353 to
4db40b9
Compare
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
Re rust-analyzer blocker, as it turns out to implement pattern types (to a degree that would unblock this) it comes down to the same architecture changes required as for rust-lang/rust-analyzer#7434 (which I am currently looking into), so that will take a bit. |
This comment has been minimized.
This comment has been minimized.
4db40b9 to
0afd16b
Compare
This comment has been minimized.
This comment has been minimized.
0afd16b to
ed90eb8
Compare
This comment has been minimized.
This comment has been minimized.
ed90eb8 to
9514a86
Compare
This comment has been minimized.
This comment has been minimized.
9514a86 to
9774687
Compare
This comment has been minimized.
This comment has been minimized.
|
Some changes occurred to the CTFE machinery cc @rust-lang/wg-const-eval Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri |
This comment has been minimized.
This comment has been minimized.
b329461 to
e2e8462
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #143582) made this pull request unmergeable. Please resolve the merge conflicts. |
e2e8462 to
620b791
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #144249) made this pull request unmergeable. Please resolve the merge conflicts. |
620b791 to
a040d40
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #143897) made this pull request unmergeable. Please resolve the merge conflicts. |
a040d40 to
85a0942
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #144814) made this pull request unmergeable. Please resolve the merge conflicts. |
85a0942 to
b5ed78d
Compare
|
This PR was rebased onto a different master 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. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Add proper name mangling for pattern types requires adding demangler support first rust-lang/rustc-demangle#81 needed for rust-lang#136006 (comment) as otherwise we will have symbol collisions
Rollup merge of #142401 - oli-obk:pattern-mango, r=petrochenkov Add proper name mangling for pattern types requires adding demangler support first rust-lang/rustc-demangle#81 needed for #136006 (comment) as otherwise we will have symbol collisions
Add proper name mangling for pattern types requires adding demangler support first rust-lang/rustc-demangle#81 needed for rust-lang/rust#136006 (comment) as otherwise we will have symbol collisions
|
☔ The latest upstream changes (presumably #142771) made this pull request unmergeable. Please resolve the merge conflicts. |
…BoxyUwU Add NonNull pattern types These are the final piece missing for * rust-lang#136006 We cannot use the previous scheme of using an integer range for raw pointers, as we're not just changing the layout of raw pointers anymore, but also the type representation. And we can't represent "any provenance or NonZero<usize>" natively as patterns. So I created a new `!null` pattern. Since this is all unstable representation stuff for replacing rustc_layout_scalar_range_start with pattern types, the divergence from normal patterns is fine, especially since T-lang seems interested in exploring general negation patterns r? `@BoxyUwU`
Add NonNull pattern types These are the final piece missing for * rust-lang/rust#136006 We cannot use the previous scheme of using an integer range for raw pointers, as we're not just changing the layout of raw pointers anymore, but also the type representation. And we can't represent "any provenance or NonZero<usize>" natively as patterns. So I created a new `!null` pattern. Since this is all unstable representation stuff for replacing rustc_layout_scalar_range_start with pattern types, the divergence from normal patterns is fine, especially since T-lang seems interested in exploring general negation patterns r? `@BoxyUwU`
cc #135996
blocked on rust-analyzer getting support for computing the right layout for pattern types
cc @Veykril no rush here, as long as we can't replace
NonNull, there's no point in doing this change just yet