Allow using stable os::fd::raw items through unstable os::wasi module

[bstrie]

This fixes a regression from stable to nightly.

Closes #99502.

[rustbot]

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

[rust-highfive]

r? @joshtriplett

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

[Aaron1011]

Can you add a test for this?

[yaahc]

r=me once the test is added

[bstrie]

I'm happy to add a test, but I don't know where in the test suite it would live. I don't really want a unit test, because it will be ruined if anyone ever adds feature(wasi_ext) to std. A doctest doesn't really make sense. And I don't know which of the litany of folders under src/test is most suitable. Any guidance?

[yaahc]

@bstrie add them to this test: https://github.com/rust-lang/rust/blob/master/src/test/ui/stability-attribute/accidental-stable-in-unstable.rs

[bstrie]

I've added a test to ensure these items are available on stable. I didn't add them to the existing accidentally-stable-in-unstable test because these items are specific to the the wasm32-wasi target and I didn't want to force that entire test to be built for wasm32-wasi, so I created a new test, accidentally-stable-in-unstable-wasi. This also required teaching compiletest a little about the wasm32-wasi target, which I did in a separate commit.

[bstrie]

There's some question on Zulip as to whether or not the test that I've added will actually be run in practice. Since I had to modify compiletest to get this test to run, I assume that it's not currently set up to run any wasm32-wasi tests (even check-pass tests like this one). So should I remove the test? Should I leave it, and expect it to never get run? Should I find a way to get the test to run during CI (which might be a bit of a large project, I'd like to get this regression fixed before the next beta is cut...)?

[bstrie]

I've removed the test, since @yaahc indicated on Zulip that she's fine with not adding a test for this. I'm happy to open a follow-up issue to track adding a test for this if anyone thinks that's necessary.

[yaahc]

@bors r+

[bors]

📌 Commit 0eb28ab has been approved by yaahc

It is now in the queue for this repository.