Provide NonZero_c_* integers #82228
Merged
Provide NonZero_c_* integers #82228
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @KodrAus (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Given that That is, couldn't this just be a bunch of type aliases for the existing NonZero types added to (Regardless of your personal feelings about the choice for Also, I personally think |
ijackson
force-pushed
the
nonzero-cint
branch
from
96e4dd0
to
367f23f
Compare
|
Thom Chiovoloni writes ("Re: [rust-lang/rust] Provide NonZero_c_* integers (#82228)"):
Given that c_int isn't a typesafe wrapper around e.g. i32, it seems
reasonable to just have std::num::NonZero_c_int be a type alias for
e.g. NonZeroI32.
That is, couldn't this just be a bunch of type aliases for the
existing NonZero types added to std::os::raw?
Hrm, you make a good point. I will think about this.
(Regardless of your personal feelings about the choice for c_int to
behave this way, it seems better to be consistent, no?)
...
Also, I personally think NonZeroCInt would be better a prettier color for the
bikeshed than NonZero_c_int.
Haha :-). NonZero_c_int has the virtue that grepping for `c_int`
might find it... I thought it was more important to be consistent
with std::os::raw than with std::num. But I can change this if the
general feeling is against me.
Ian.
…--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
|
This file contained a lot of repetitive code. This was about to get considerably worse, with introduction of a slew of new aliases. No functional change. I've eyeballed the docs and they don't seem to have changed either. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
I'm pretty sure I am going want this for rust-lang#73125 and it seems like an omission that would be in any case good to remedy. It's a shame we don't have competent token pasting and case mangling for use in macro_rules!. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
ijackson
force-pushed
the
nonzero-cint
branch
from
367f23f
to
e78b501
Compare
Thanks for the suggestion. I did this and it came out quite a lot nicer to implement too. |
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Feb 21, 2021
…k-Simulacrum try-back-block-type test: Use TryFromSliceError for From test Using `i32` is rather fragile because it has many implementations. Recently in an early draft of another MR (rust-lang#82228) I did something that introduced a new `i32 as From<something>` impl and this test broke. TryFromSliceError is nice because it doesn't seem likely to grow new conversions. We still have one conversion, from Infallible. My other MR is going to be reworked and won't need this any more but having done it I thought I would submit it rather than just throw it away. Sorry for the tiny MR.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Feb 21, 2021
…k-Simulacrum try-back-block-type test: Use TryFromSliceError for From test Using `i32` is rather fragile because it has many implementations. Recently in an early draft of another MR (rust-lang#82228) I did something that introduced a new `i32 as From<something>` impl and this test broke. TryFromSliceError is nice because it doesn't seem likely to grow new conversions. We still have one conversion, from Infallible. My other MR is going to be reworked and won't need this any more but having done it I thought I would submit it rather than just throw it away. Sorry for the tiny MR.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Feb 21, 2021
…k-Simulacrum try-back-block-type test: Use TryFromSliceError for From test Using `i32` is rather fragile because it has many implementations. Recently in an early draft of another MR (rust-lang#82228) I did something that introduced a new `i32 as From<something>` impl and this test broke. TryFromSliceError is nice because it doesn't seem likely to grow new conversions. We still have one conversion, from Infallible. My other MR is going to be reworked and won't need this any more but having done it I thought I would submit it rather than just throw it away. Sorry for the tiny MR.
4 tasks
|
📌 Commit 60a9dcc has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 22, 2021
Rollup of 9 pull requests Successful merges: - rust-lang#82098 (Add internal `collect_into_array[_unchecked]` to remove duplicate code) - rust-lang#82228 (Provide NonZero_c_* integers) - rust-lang#82287 (Make "missing field" error message more natural) - rust-lang#82351 (Use the first paragraph, instead of cookie-cutter text, for rustdoc descriptions) - rust-lang#82353 (rustdoc: Remove unnecessary `Cell` around `param_env`) - rust-lang#82367 (remove redundant option/result wrapping of return values) - rust-lang#82372 (improve UnsafeCell docs) - rust-lang#82379 (Fix sizes of repr(C) enums on hexagon) - rust-lang#82382 (rustdoc: Remove `fake_def_ids` RefCell) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm pretty sure I am going want this for #73125 and it seems like an
omission that would be in any case good to remedy.
Because the raw C types are instd, notcore, to achieve this wemust export the relevant macros from
coreso thatstdcan usethem. That's done with a new
num_internalsperma-unstable feature.The macros need to take more parameters for the module to get the
types from and feature attributes to use.
I have eyeballed the docs output for core, to check that my changes tothese macros have made no difference to the core docs output.