-
Couldn't load subscription status.
- 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.
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 comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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`
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`
b5ed78d to
cbc6ae6
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. |
This comment has been minimized.
This comment has been minimized.
Use `!null` pattern type in libcore
cbc6ae6 to
466688c
Compare
|
Some changes occurred in compiler/rustc_codegen_gcc |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
cc #135996