Mark std::os::wasi::io::AsFd etc. as stable. by sunfishcode · Pull Request #103308 · rust-lang/rust (original) (raw)

io_safety was stabilized in Rust 1.63, so mark the io_safety exports in std::os::wasi::io as stable.

Fixes #103306.

io_safety was stabilized in Rust 1.63, so mark the io_safety exports in std::os::wasi::io as stable.

Fixes rust-lang#103306.

rustbot added the T-libs

Relevant to the library team, which will review and decide on the PR/issue.

label

Oct 20, 2022

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

This probably should also be beta (and stable?) nominated, so doing that now.

📌 Commit e56b84e has been approved by joshtriplett

It is now in the queue for this repository.

bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Oct 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you also need the module itself to be stable?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, you're right. Fixed now.

📌 Commit 7ac645a has been approved by joshtriplett

It is now in the queue for this repository.

Finished benchmarking commit (b1ab3b7): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request

Oct 29, 2022

This was referenced

Oct 29, 2022

bors added a commit to rust-lang-ci/rust that referenced this pull request

Oct 29, 2022

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Nov 15, 2022

…ized, r=JohnTitor

Adjust stabilization version to 1.65.0 for wasi fds

See rust-lang#103308 (comment) for this ask.

Backport of that PR to beta (1.65.0) will include a similar patch.

thomcc pushed a commit to tcdi/postgrestd that referenced this pull request

Feb 10, 2023

thomcc pushed a commit to tcdi/postgrestd that referenced this pull request

Feb 10, 2023

…ohnTitor

Adjust stabilization version to 1.65.0 for wasi fds

See rust-lang/rust#103308 (comment) for this ask.

Backport of that PR to beta (1.65.0) will include a similar patch.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request

Jan 19, 2025

…_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.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request

Jan 19, 2025

…_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.

jieyouxu added a commit to jieyouxu/rust that referenced this pull request

Jan 20, 2025

…_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.

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Jan 20, 2025

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.

github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this pull request

Mar 11, 2025

…_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.