-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Move OsStringExt
and OsStrExt
to std::os
#84967
Conversation
r? @m-ou-se (rust-highfive has picked a reviewer for you, use r? to override) |
@@ -34,5 +34,68 @@ | |||
|
|||
#![unstable(feature = "sgx_platform", issue = "56975")] | |||
|
|||
#[unstable(feature = "sgx_platform", issue = "56975")] |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment has been minimized.
This comment has been minimized.
// FIXME: | ||
// `Buf::as_slice` current implementation relies | ||
// on `Slice` being layout-compatible with `[u8]`. | ||
// When attribute privacy is implemented, `Slice` should be annotated as `#[repr(transparent)]`. | ||
// Anyway, `Slice` representation and layout are considered implementation detail, are | ||
// not documented and must not be relied upon. | ||
pub(crate) struct Slice { | ||
#[repr(transparent)] | ||
pub struct Slice { |
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.
Because Buf
and Slice
now no longer live in a publicly exported module they can be marked as pub
and repr(transparent)
as normal.
☔ The latest upstream changes (presumably #85518) made this pull request unmergeable. Please resolve the merge conflicts. |
I don't think we should be duplicating this. Duplication in It might be good to have each platform opt-in to these extensions instead of just using |
…e is reused on other platforms.
I tried another approach of reusing code within One potential problem I could think of is that it is more easy to forget that a file is reused on other platforms, more so than in What are your thoughts on this approach? If you approve I could later look into if there are more files in |
Thanks! This looks very reasonable to me. We could also have a @bors r+ |
📌 Commit ad7b897 has been approved by |
☀️ Test successful - checks-actions |
Move `os_str_bytes` to `sys::unix` Followup to rust-lang#84967, with `OsStrExt` and `OsStringExt` moved out of `sys_common`, there is no reason anymore for `os_str_bytes` to live in `sys_common` and not in sys. This pr moves it to the location `sys::unix::os_str` and reuses the code on other platforms via `#[path]` (as is common in `sys`) instead of importing.
Moves the
OsStringExt
andOsStrExt
traits and implementations fromsys_common
toos
.sys_common
is for abstractions oversys
and shouldn't really contain publicly exported items.This does introduce some duplication: the traits and implementations are now duplicated in
unix
,wasi
,hermit
, andsgx
. However, I would argue that this duplication is no different to how something likeMetadataExt
is duplicated inlinux
,vxworkx
,redox
,solaris
etc. The duplication also matches the fact that the traits on different platforms are technically distinct types: any platform is free to add it's own extra methods to the extension trait.