Make std::os::fd public.
#98368
Make std::os::fd public.
#98368
Conversation
rustbot
added
the
T-libs
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
rust-highfive
added
the
S-waiting-on-review
joshtriplett
added
S-waiting-on-author
|
@rfcbot merge |
This comment was marked as outdated.
This comment was marked as outdated.
rfcbot
added
proposed-final-comment-period
|
Would it be possible to get a listing of everything that is being proposed to be stabilized at a path inside @rfcbot concern what are the contents |
|
@dtolnay The contents of the
The platforms this PR adds the In the future, it's possible that fortanix_sgx and/or solid may want to add this module as well, as they also have similar types and traits. |
|
Is this insta-stable? The other thing I'm confused about here is why things like |
|
I think the idea is that we already have |
|
@dtolnay Ah I see thanks, I think that makes sense. @sunfishcode Can we add that guidance to the docs of I do admit though that this feels a little strange to me to be honest. I like the practicality behind this, but I think you still have to gate |
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
Yes, I guess it currently is. Would it be better here to use
I've clarified the comment to explicitly mention both Unix and WASI.
It does already have conditional compilation; the |
Hmmm, I suppose, yes. I was more referring to consumers of this API. The import path doesn't really make it clear (like other import paths do) that conditional compilation is needed. It's just a departure from what we've done, I think. The fact that |
I'm not sure of the underlying mechanism, but basically, if we don't have to do this as insta-stable, then we probably shouldn't. The typical insta-stable things are trait impls, and I believe that's because there just isn't any alternative. |
I've now filed a tracking issue #98699, and updated the PR to use a |
|
@rfcbot fcp cancel |
|
@dtolnay proposal cancelled. |
rfcbot
removed
proposed-final-comment-period
…r=joshtriplett Make `std::os::fd` public. `std::os::fd` defines types like `OwnedFd` and `RawFd` and is common between Unix and non-Unix platforms that share a basic file-descriptor concept. Rust currently uses this internally to simplify its own code, but it would be useful for external users in the same way, so make it public. This means that `OwnedFd` etc. will all appear in three places, for example on unix platforms: - `std::os::fd::OwnedFd` - `std::os::unix::io::OwnedFd` - `std::os::unix::prelude::OwnedFd` r? `@joshtriplett`
…r=joshtriplett Make `std::os::fd` public. `std::os::fd` defines types like `OwnedFd` and `RawFd` and is common between Unix and non-Unix platforms that share a basic file-descriptor concept. Rust currently uses this internally to simplify its own code, but it would be useful for external users in the same way, so make it public. This means that `OwnedFd` etc. will all appear in three places, for example on unix platforms: - `std::os::fd::OwnedFd` - `std::os::unix::io::OwnedFd` - `std::os::unix::prelude::OwnedFd` r? ``@joshtriplett``
…r=joshtriplett Make `std::os::fd` public. `std::os::fd` defines types like `OwnedFd` and `RawFd` and is common between Unix and non-Unix platforms that share a basic file-descriptor concept. Rust currently uses this internally to simplify its own code, but it would be useful for external users in the same way, so make it public. This means that `OwnedFd` etc. will all appear in three places, for example on unix platforms: - `std::os::fd::OwnedFd` - `std::os::unix::io::OwnedFd` - `std::os::unix::prelude::OwnedFd` r? ```@joshtriplett```
…r=joshtriplett Make `std::os::fd` public. `std::os::fd` defines types like `OwnedFd` and `RawFd` and is common between Unix and non-Unix platforms that share a basic file-descriptor concept. Rust currently uses this internally to simplify its own code, but it would be useful for external users in the same way, so make it public. This means that `OwnedFd` etc. will all appear in three places, for example on unix platforms: - `std::os::fd::OwnedFd` - `std::os::unix::io::OwnedFd` - `std::os::unix::prelude::OwnedFd` r? ````@joshtriplett````
Rollup of 8 pull requests Successful merges: - rust-lang#98368 (Make `std::os::fd` public.) - rust-lang#102085 (Code refactoring smart_resolve_report_errors) - rust-lang#102351 (Improve E0585 help) - rust-lang#102368 (Add a niche to `Duration`, unix `SystemTime`, and non-apple `Instant`) - rust-lang#102393 (Add regression test for issue 94923) - rust-lang#102399 (Account for use of index-based lifetime names in print of binder) - rust-lang#102416 (remove FIXME, improve documentation) - rust-lang#102433 (env::temp_dir: fix a typo) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
As @bjorn3 pointed out [here], I used the wrong stability attribute in rust-lang#98368 when making `std::os::fd` public. I set it to Rust 1.63, which was when io-safety was stabilized, but it should be Rust 1.66, which was when `std::os::fd` was stabilized. [here]: rust-lang#98368 (comment)
…stable-version, r=m-ou-se Fix the stability attributes for `std::os::fd`. As `@bjorn3` pointed out [here], I used the wrong stability attribute in rust-lang#98368 when making `std::os::fd` public. I set it to Rust 1.63, which was when io-safety was stabilized, but it should be Rust 1.66, which was when `std::os::fd` was stabilized. [here]: rust-lang#98368 (comment)
As @bjorn3 pointed out [here], I used the wrong stability attribute in #98368 when making `std::os::fd` public. I set it to Rust 1.63, which was when io-safety was stabilized, but it should be Rust 1.66, which was when `std::os::fd` was stabilized. [here]: rust-lang/rust#98368 (comment)
…rsion, r=m-ou-se Fix the stability attributes for `std::os::fd`. As `@bjorn3` pointed out [here], I used the wrong stability attribute in #98368 when making `std::os::fd` public. I set it to Rust 1.63, which was when io-safety was stabilized, but it should be Rust 1.66, which was when `std::os::fd` was stabilized. [here]: rust-lang/rust#98368 (comment)
| #![unstable(feature = "wasi_ext", issue = "71213")] | ||
|
|
||
| mod fd; | ||
| mod raw; |
There was a problem hiding this comment.
This removed two mod statements but the corresponding files still exist. I think they are dead now? Or is there some magic going on that somehow loads them anyway?
There was a problem hiding this comment.
They're indeed dead now. I've now filed #135512 to remove them.
There was a problem hiding this comment.
And I've now noticed that #135491 already does this, so closing in favor off that.
As noticed [here], these two files are no longer used. [here]: rust-lang#98368 (review)
…_through_unstable_modules, r=Mark-Simulacrum Remove dead rustc_allowed_through_unstable_modules for std::os::fd contents As far as I was able to reconstruct, the history here is roughly as follows: - rust-lang#99723 added some `rustc_allowed_through_unstable_modules` to the types in `std::os::fd::raw` since they were accessible on stable via the unstable `std::os::wasi::io::AsRawFd` path. (This was needed to fix rust-lang#99502.) - Shortly thereafter, rust-lang#98368 re-organized things so that instead of re-exporting from an internal `std::os::wasi::io::raw`, `std::os::wasi::io::AsRawFd` is now directly re-exported from `std::os::fd`. This also made `library/std/src/os/wasi/io/raw.rs` entirely dead code as far as I can tell, it's not imported by anything any more. - Shortly thereafter, rust-lang#103308 stabilizes `std::os::wasi::io`, so `rustc_allowed_through_unstable_modules` is not needed any more to access `std::os::wasi::io::AsRawFd`. There is even a comment in `library/std/src/os/wasi/io/raw.rs` saying the attribute can be removed now, but that file is dead code so it is not touched as part of the stabilization. I did a grep for `pub use crate::os::fd` and all the re-exports I could find are in stable modules. So given all that, we can remove the `rustc_allowed_through_unstable_modules` (hoping they are not also re-exported somewhere else, it's really hard to be sure about this). I have checked that std still builds after this PR on the wasm32-wasip2 target.
…_through_unstable_modules, r=Mark-Simulacrum Remove dead rustc_allowed_through_unstable_modules for std::os::fd contents As far as I was able to reconstruct, the history here is roughly as follows: - rust-lang#99723 added some `rustc_allowed_through_unstable_modules` to the types in `std::os::fd::raw` since they were accessible on stable via the unstable `std::os::wasi::io::AsRawFd` path. (This was needed to fix rust-lang#99502.) - Shortly thereafter, rust-lang#98368 re-organized things so that instead of re-exporting from an internal `std::os::wasi::io::raw`, `std::os::wasi::io::AsRawFd` is now directly re-exported from `std::os::fd`. This also made `library/std/src/os/wasi/io/raw.rs` entirely dead code as far as I can tell, it's not imported by anything any more. - Shortly thereafter, rust-lang#103308 stabilizes `std::os::wasi::io`, so `rustc_allowed_through_unstable_modules` is not needed any more to access `std::os::wasi::io::AsRawFd`. There is even a comment in `library/std/src/os/wasi/io/raw.rs` saying the attribute can be removed now, but that file is dead code so it is not touched as part of the stabilization. I did a grep for `pub use crate::os::fd` and all the re-exports I could find are in stable modules. So given all that, we can remove the `rustc_allowed_through_unstable_modules` (hoping they are not also re-exported somewhere else, it's really hard to be sure about this). I have checked that std still builds after this PR on the wasm32-wasip2 target.
…_through_unstable_modules, r=Mark-Simulacrum Remove dead rustc_allowed_through_unstable_modules for std::os::fd contents As far as I was able to reconstruct, the history here is roughly as follows: - rust-lang#99723 added some `rustc_allowed_through_unstable_modules` to the types in `std::os::fd::raw` since they were accessible on stable via the unstable `std::os::wasi::io::AsRawFd` path. (This was needed to fix rust-lang#99502.) - Shortly thereafter, rust-lang#98368 re-organized things so that instead of re-exporting from an internal `std::os::wasi::io::raw`, `std::os::wasi::io::AsRawFd` is now directly re-exported from `std::os::fd`. This also made `library/std/src/os/wasi/io/raw.rs` entirely dead code as far as I can tell, it's not imported by anything any more. - Shortly thereafter, rust-lang#103308 stabilizes `std::os::wasi::io`, so `rustc_allowed_through_unstable_modules` is not needed any more to access `std::os::wasi::io::AsRawFd`. There is even a comment in `library/std/src/os/wasi/io/raw.rs` saying the attribute can be removed now, but that file is dead code so it is not touched as part of the stabilization. I did a grep for `pub use crate::os::fd` and all the re-exports I could find are in stable modules. So given all that, we can remove the `rustc_allowed_through_unstable_modules` (hoping they are not also re-exported somewhere else, it's really hard to be sure about this). I have checked that std still builds after this PR on the wasm32-wasip2 target.
Rollup merge of rust-lang#135491 - RalfJung:remove-dead-rustc_allowed_through_unstable_modules, r=Mark-Simulacrum Remove dead rustc_allowed_through_unstable_modules for std::os::fd contents As far as I was able to reconstruct, the history here is roughly as follows: - rust-lang#99723 added some `rustc_allowed_through_unstable_modules` to the types in `std::os::fd::raw` since they were accessible on stable via the unstable `std::os::wasi::io::AsRawFd` path. (This was needed to fix rust-lang#99502.) - Shortly thereafter, rust-lang#98368 re-organized things so that instead of re-exporting from an internal `std::os::wasi::io::raw`, `std::os::wasi::io::AsRawFd` is now directly re-exported from `std::os::fd`. This also made `library/std/src/os/wasi/io/raw.rs` entirely dead code as far as I can tell, it's not imported by anything any more. - Shortly thereafter, rust-lang#103308 stabilizes `std::os::wasi::io`, so `rustc_allowed_through_unstable_modules` is not needed any more to access `std::os::wasi::io::AsRawFd`. There is even a comment in `library/std/src/os/wasi/io/raw.rs` saying the attribute can be removed now, but that file is dead code so it is not touched as part of the stabilization. I did a grep for `pub use crate::os::fd` and all the re-exports I could find are in stable modules. So given all that, we can remove the `rustc_allowed_through_unstable_modules` (hoping they are not also re-exported somewhere else, it's really hard to be sure about this). I have checked that std still builds after this PR on the wasm32-wasip2 target.
std::os::fddefines types likeOwnedFdandRawFdand is commonbetween Unix and non-Unix platforms that share a basic file-descriptor
concept. Rust currently uses this internally to simplify its own code,
but it would be useful for external users in the same way, so make it
public.
This means that
OwnedFdetc. will all appear in three places, forexample on unix platforms:
std::os::fd::OwnedFdstd::os::unix::io::OwnedFdstd::os::unix::prelude::OwnedFdr? @joshtriplett