-
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
Move unix_socket_abstract
feature API to SocketAddrExt
.
#101967
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon. Please see the contribution instructions for more information. |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
LGTM. All the stability attributes look fine. |
@rustbot label +T-libs-api -T-libs |
Note: posted an LGTM above, but would appreciate a second set of eyes on this. |
Gentle ping. |
@bors r+ rollup |
…dr, r=joshtriplett Move `unix_socket_abstract` feature API to `SocketAddrExt`. The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered. This PR makes four changes: 1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there. 2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change). 3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer. 4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly. Issues: 1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
…dr, r=joshtriplett Move `unix_socket_abstract` feature API to `SocketAddrExt`. The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered. This PR makes four changes: 1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there. 2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change). 3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer. 4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly. Issues: 1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#101967 (Move `unix_socket_abstract` feature API to `SocketAddrExt`.) - rust-lang#102470 (Stabilize const char convert) - rust-lang#104223 (Recover from function pointer types with generic parameter list) - rust-lang#104229 (Don't print full paths in overlap errors) - rust-lang#104294 (Don't ICE with inline const errors during MIR build) - rust-lang#104332 (Fixed some `_i32` notation in `maybe_uninit`’s doc) - rust-lang#104349 (fix some typos in comments) - rust-lang#104350 (Fix x finding Python on Windows) - rust-lang#104356 (interpret: make check_mplace public) - rust-lang#104364 (rustdoc: Resolve doc links in external traits having local impls) - rust-lang#104378 (Bump chalk to v0.87) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This is awesome !! |
The pre-stabilized API for abstract socket addresses exposes methods on
SocketAddr
that are only enabled forcfg(any(target_os = "android", target_os = "linux"))
. Per discussion in #85410, moving these methods to an OS-specific extension trait is required before stabilization can be considered.This PR makes four changes:
std::os::net
contains logic for the unstable featuretcp_quickack
(Tracking Issue for TCP_QUICKACK support on Linux #96256). I moved that code intolinux_ext/tcp.rs
and tried to adjust the module tree so it could accommodate a second unstable feature there.impl SocketAddr
, intoimpl SocketAddrExt for SocketAddr
(the headline change).unix_socket_abstract
refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in the abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer.from_abstract_name
so it takes anAsRef<[u8]>
instead of&[u8]
, allowingb""
literals to be passed directly.Issues:
std::os::linux::net
is marked as part oftcp_quickack
. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.