-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add #[repr(transparent)] for several types #61969
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Also note that we don't really need repr(transparent) to justify the transmutes. They're all in libstd, which is tied to a specific compiler version (and updated in tandem with rustc) and privileged (in fact, required) to exploit additional knowledge about the compiler that other code doesn't get to rely on. (Not that this is something we're ever expected to change. Indeed I've never seen anyone seriously argue that |
I agree that some code in libstd has to rely on compiler internals. Also, many other std types which are transmuted do have #[repr(transparent)], e.g. UnsafeCell. So, situation where CStr is not #[repr(transparent)], but UnsafeCell is, doesn't seem consistent to my mind. |
As @Centril noted, marking (public) types repr(transparent) is a commitment that we may not (in the case of CStr, definitely do not) want to make. That's why some types don't have it. |
Instead of a semver commitment, I would leave comments on type definitions as well as where the transmutes happen with explicit disclaimers for users reading those about not being semver guarantees. |
Reassigning this to @Centril and marking as waiting-on-author. This PR will want to be updated to remove the Ideally, though, I think we should discuss a way -- if it doesn't exist -- for us to make |
src/libstd/ffi/c_str.rs
Outdated
@@ -195,6 +195,7 @@ pub struct CString { | |||
/// [`from_ptr`]: #method.from_ptr | |||
#[derive(Hash)] | |||
#[stable(feature = "rust1", since = "1.0.0")] | |||
// #[repr(transparent)] FIXME: should be enabled, when attribute privacy is implemented |
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.
Can you add something like:
// We rely on this internally, but this is *not* a stability guarantee.
as well?
r=me rollup when green with comment above ^-- addressed in some fashion. |
Ping from triage: @MikailBag, waiting on your response, all you have to do is add a comment. |
Currently I'm vacation, and don't have access to my PC) |
Sorry for delay. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The textual changes you made look but you'll need to add some line-breaks to pacify the r=me rollup once that is done. |
Oh, it seems you didn't get any notifications. |
Thanks! @bors r+ rollup |
📌 Commit 740f8db has been approved by |
Add #[repr(transparent)] for several types In some functions, types mentioned in this PR are transmuted into their inner value. Example for `PathBuf`: https://github.com/rust-lang/rust/blob/master/src/libstd/path.rs#L1132. This PR adds `#[repr(transparent)]` to those types, so their correct behavior doesn't depend on compiler details. (As far as I understand, currently that line, converting `PathBuf` to `Vec<u8>`, is UB).
Rollup of 8 pull requests Successful merges: - #61969 (Add #[repr(transparent)] for several types) - #62108 (Use sharded maps for queries) - #63149 (resolve: Populate external modules in more automatic and lazy way) - #63346 (Lint on some incorrect uses of mem::zeroed / mem::uninitialized) - #63433 (Miri shouldn't look at types) - #63440 (rename RUST_CTFE_BACKTRACE to RUSTC_CTFE_BACKTRACE) - #63442 (Add an example to show how to insert item to a sorted vec) - #63459 (syntax: account for CVarArgs being in the argument list.) Failed merges: r? @ghost
Add #[repr(transparent)] for several types In some functions, types mentioned in this PR are transmuted into their inner value. Example for `PathBuf`: https://github.com/rust-lang/rust/blob/master/src/libstd/path.rs#L1132. This PR adds `#[repr(transparent)]` to those types, so their correct behavior doesn't depend on compiler details. (As far as I understand, currently that line, converting `PathBuf` to `Vec<u8>`, is UB).
Rollup of 8 pull requests Successful merges: - #61969 (Add #[repr(transparent)] for several types) - #63346 (Lint on some incorrect uses of mem::zeroed / mem::uninitialized) - #63433 (Miri shouldn't look at types) - #63440 (rename RUST_CTFE_BACKTRACE to RUSTC_CTFE_BACKTRACE) - #63441 (Derive Debug for CrateInfo) - #63442 (Add an example to show how to insert item to a sorted vec) - #63453 (rustdoc: general cleanup) - #63464 (Copy ty::Instance instead of passing by reference) Failed merges: r? @ghost
Hide repr attribute from doc of types without guaranteed repr Rustdoc has an undesirable behavior of blindly copying `repr` into the documentation of structs and enums, even when there is no particular repr that the type guarantees to its users. This is a source of confusion for standard library users who assume the fact that a repr is documented means it must be something the standard library promises they can rely on (in transmutes, or FFI). Some issues on the topic of rustdoc's incorrect handling of `repr`: - rust-lang#66401 - rust-lang#90435 In places, the standard library currently works around this confusing rustdoc behavior by just omitting `repr(transparent)` altogether even where it should be required if equivalent code were being written outside of the standard library. See rust-lang#61969. IMO that is even more confusing, even for standard library maintainers — see rust-lang#105018 (comment). It's also not something that works for other reprs like `C` or `u8` which cannot just be omitted even in standard library code. This PR tries a different approach for some types that are being currently incorrectly documented with a repr. > **Warning** > This PR does not imply that every type that still has a `repr` attribute in its docs after this PR is now public for users to rely on. This PR only tries to reduce harm from this longstanding rustdoc issue.
In some functions, types mentioned in this PR are transmuted into their inner value.
Example for
PathBuf
: https://github.com/rust-lang/rust/blob/master/src/libstd/path.rs#L1132.This PR adds
#[repr(transparent)]
to those types, so their correct behavior doesn't depend on compiler details. (As far as I understand, currently that line, convertingPathBuf
toVec<u8>
, is UB).