Skip to content

Regression on nightly when compiling mio for wasm32-wasi #99502

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
Closed
bstrie opened this issue Jul 20, 2022 · 4 comments · Fixed by #99723 or #135491
Closed

Regression on nightly when compiling mio for wasm32-wasi #99502

bstrie opened this issue Jul 20, 2022 · 4 comments · Fixed by #99723 or #135491
Labels
C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@bstrie
Copy link
Contributor

bstrie commented Jul 20, 2022 •
edited
Loading

Steps to reproduce:

$ rustup toolchain install 1.62.1 --target wasm32-wasi
$ rustup toolchain install nightly-2022-07-19 --target wasm32-wasi
$ git clone https://github.com/tokio-rs/mio.git
$ cd mio
$ git checkout v0.8.4
$ cargo +1.62.1 build --target wasm32-wasi --all-features
   Compiling libc v0.2.126
   Compiling log v0.4.17
   Compiling cfg-if v1.0.0
   Compiling wasi v0.11.0+wasi-snapshot-preview1
   Compiling mio v0.8.4 (/home/ben/code/mio)
    Finished dev [unoptimized + debuginfo] target(s) in 0.66s
$ cargo +nightly-2022-07-19 build --target wasm32-wasi --all-features
   Compiling log v0.4.17
   Compiling libc v0.2.126
   Compiling cfg-if v1.0.0
   Compiling wasi v0.11.0+wasi-snapshot-preview1
   Compiling mio v0.8.4 (/home/ben/code/mio)
error[E0658]: use of unstable library feature 'wasi_ext'
 --> src/io_source.rs:5:5
  |
5 | use std::os::wasi::io::AsRawFd;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #71213 <https://github.com/rust-lang/rust/issues/71213> for more information
  = help: add `#![feature(wasi_ext)]` to the crate attributes to enable

For more information about this error, try `rustc --explain E0658`.
error: could not compile `mio` due to previous error

It's possible that this was accidentally stabilized, then feature gated later.
@bstrie bstrie added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Jul 20, 2022
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Jul 20, 2022
@ehuss
Copy link
Contributor

ehuss commented Jul 20, 2022

This seems to be caused by #95956.

I was thinking #99292 might address this, but I tried that PR and it doesn't seem to work. Maybe @Aaron1011 can confirm.

cc @yaahc

@yaahc
Copy link
Member

yaahc commented Jul 20, 2022

Looks like another case of #99288, AsRawFd is stable but the std::os::wasi::io module it lives in is not: https://doc.rust-lang.org/stable/std/os/wasi/io/index.html

Just need to add #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] and it should work.

@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 21, 2022
@bstrie
Copy link
Contributor Author

bstrie commented Jul 21, 2022

I'll work on this.

This was referenced Jul 21, 2022
Open
Merged
@bstrie
Copy link
Contributor Author

bstrie commented Jul 25, 2022

@yaahc Using your suggested fix, I have a simple PR to address this, if you'd like to review: #99723 . I've confirmed locally that a toolchain built with this patch fixes the regression.

@apiraino apiraino added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 27, 2022
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jul 27, 2022
@GuillaumeGomez
Rollup merge of rust-lang#99723 - bstrie:wasifd, r=yaahc
46e21aa 
Allow using stable os::fd::raw items through unstable os::wasi module

This fixes a regression from stable to nightly.

Closes rust-lang#99502.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jul 27, 2022
@GuillaumeGomez
Rollup merge of rust-lang#99723 - bstrie:wasifd, r=yaahc
494808f 
Allow using stable os::fd::raw items through unstable os::wasi module

This fixes a regression from stable to nightly.

Closes rust-lang#99502.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 28, 2022
@Dylan-DPC
Rollup merge of rust-lang#99723 - bstrie:wasifd, r=yaahc
5996733 
Allow using stable os::fd::raw items through unstable os::wasi module

This fixes a regression from stable to nightly.

Closes rust-lang#99502.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 28, 2022
@Dylan-DPC
Rollup merge of rust-lang#99723 - bstrie:wasifd, r=yaahc
f326692 
Allow using stable os::fd::raw items through unstable os::wasi module

This fixes a regression from stable to nightly.

Closes rust-lang#99502.
@bors bors closed this as completed in 0eb28ab Jul 28, 2022
@apiraino apiraino removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label May 16, 2023
@RalfJung RalfJung mentioned this issue Jan 14, 2025
Merged
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jan 19, 2025
@GuillaumeGomez
Rollup merge of rust-lang#135491 - RalfJung:remove-dead-rustc_allowed…
a6051c7 
…_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 issue Jan 19, 2025
@GuillaumeGomez
Rollup merge of rust-lang#135491 - RalfJung:remove-dead-rustc_allowed…
e96817a 
…_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 issue Jan 20, 2025
@jieyouxu
Rollup merge of rust-lang#135491 - RalfJung:remove-dead-rustc_allowed…
e1e26f3 
…_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 issue Jan 20, 2025
@rust-timer
Unrolled build for rust-lang#135491
d78dcf2 
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 issue Mar 11, 2025
@jieyouxu
Rollup merge of rust-lang#135491 - RalfJung:remove-dead-rustc_allowed…
344c704 
…_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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
5 participants
@ehuss @bstrie @yaahc @apiraino @rustbot