Skip to content

Conversation

@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Dec 10, 2025

This commit is a follow-up to #147572 and the issue reported at the end of that PR where the std::fs::hard_link function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the linkat function.

This commit is a follow-up to 147572 and the issue reported at the end
of that PR where the `std::fs::hard_link` function is broken after that
PR landed. The true culprit and bug here is fixed in
WebAssembly/wasi-libc/690 but until that's released in a wasi-sdk
version it should be reasonable, on WASI, to skip the `linkat`
function.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 10, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 10, 2025

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Comment on lines -2080 to +2098
any(target_os = "vxworks", target_os = "redox", target_os = "android", target_os = "espidf", target_os = "horizon", target_os = "vita", target_env = "nto70") => {
// VxWorks, Redox and ESP-IDF lack `linkat`, so use `link` instead. POSIX leaves
// it implementation-defined whether `link` follows symlinks, so rely on the
// `symlink_hard_link` test in library/std/src/fs/tests.rs to check the behavior.
// Android has `linkat` on newer versions, but we happen to know `link`
// always has the correct behavior, so it's here as well.
any(
// VxWorks, Redox and ESP-IDF lack `linkat`, so use `link` instead.
// POSIX leaves it implementation-defined whether `link` follows
// symlinks, so rely on the `symlink_hard_link` test in
// library/std/src/fs/tests.rs to check the behavior.
target_os = "vxworks",
target_os = "redox",
target_os = "espidf",
// Android has `linkat` on newer versions, but we happen to know
// `link` always has the correct behavior, so it's here as well.
target_os = "android",
// wasi-sdk-29-and-prior have a buggy `linkat` so use `link` instead
// until wasi-sdk is updated (see WebAssembly/wasi-libc#690)
target_os = "wasi",
// Other misc platforms
target_os = "horizon",
target_os = "vita",
target_env = "nto70",
) => {
Copy link
Member Author

Choose a reason for hiding this comment

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

As a note for this I took the liberty to reformat the line to be less long and arrange the comments to apply to the platform-in-question too.

@joboet
Copy link
Member

joboet commented Dec 14, 2025

Yup, makes sense.
@bors r+

@bors
Copy link
Collaborator

bors commented Dec 14, 2025

📌 Commit 71d7ae2 has been approved by joboet

It is now in the queue for this repository.

@bors 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 Dec 14, 2025
@joboet
Copy link
Member

joboet commented Dec 14, 2025

For future reference, the relevant code in wasi-libc is

https://github.com/WebAssembly/wasi-libc/blob/76db3247be3239ef75b4b854f775ada1c1202e66/libc-bottom-half/sources/posix.c#L278-L294

which indeed calls linkat without flags, just like we do.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 14, 2025
…joboet

std: Don't use `linkat` on the `wasm32-wasi*` targets

This commit is a follow-up to rust-lang#147572 and the issue reported at the end of that PR where the `std::fs::hard_link` function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the `linkat` function.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 14, 2025
…joboet

std: Don't use `linkat` on the `wasm32-wasi*` targets

This commit is a follow-up to rust-lang#147572 and the issue reported at the end of that PR where the `std::fs::hard_link` function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the `linkat` function.
bors added a commit that referenced this pull request Dec 14, 2025
Rollup of 7 pull requests

Successful merges:

 - #146794 (std: reorganize pipe implementations)
 - #148196 (Implement create_dir_all() to operate iteratively instead of recursively)
 - #148490 (dangling pointer from temp cleanup)
 - #149864 (std: Don't use `linkat` on the `wasm32-wasi*` targets)
 - #149885 (replace addr_of_mut with &raw mut in maybeuninit docs)
 - #149949 (Cleanup of attribute parsing errors)
 - #149969 (don't use no_main and no_core to test IBT)

Failed merges:

 - #148847 (Share Timespec between Unix and Hermit)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit that referenced this pull request Dec 14, 2025
Rollup of 8 pull requests

Successful merges:

 - #146794 (std: reorganize pipe implementations)
 - #148490 (dangling pointer from temp cleanup)
 - #149837 (Update `wrapping_sh[lr]` docs and examples)
 - #149864 (std: Don't use `linkat` on the `wasm32-wasi*` targets)
 - #149885 (replace addr_of_mut with &raw mut in maybeuninit docs)
 - #149949 (Cleanup of attribute parsing errors)
 - #149969 (don't use no_main and no_core to test IBT)
 - #149998 (miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit that referenced this pull request Dec 15, 2025
Rollup of 8 pull requests

Successful merges:

 - #146794 (std: reorganize pipe implementations)
 - #148490 (dangling pointer from temp cleanup)
 - #149837 (Update `wrapping_sh[lr]` docs and examples)
 - #149864 (std: Don't use `linkat` on the `wasm32-wasi*` targets)
 - #149885 (replace addr_of_mut with &raw mut in maybeuninit docs)
 - #149949 (Cleanup of attribute parsing errors)
 - #149969 (don't use no_main and no_core to test IBT)
 - #149998 (miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit ce2eec1 into rust-lang:main Dec 15, 2025
11 checks passed
@rustbot rustbot added this to the 1.94.0 milestone Dec 15, 2025
rust-timer added a commit that referenced this pull request Dec 15, 2025
Rollup merge of #149864 - alexcrichton:wasi-avoid-linkat, r=joboet

std: Don't use `linkat` on the `wasm32-wasi*` targets

This commit is a follow-up to #147572 and the issue reported at the end of that PR where the `std::fs::hard_link` function is broken after that PR landed. The true culprit and bug here is fixed in WebAssembly/wasi-libc#690 but until that's released in a wasi-sdk version it should be reasonable, on WASI, to skip the `linkat` function.
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Dec 18, 2025
Rollup of 8 pull requests

Successful merges:

 - rust-lang/rust#146794 (std: reorganize pipe implementations)
 - rust-lang/rust#148490 (dangling pointer from temp cleanup)
 - rust-lang/rust#149837 (Update `wrapping_sh[lr]` docs and examples)
 - rust-lang/rust#149864 (std: Don't use `linkat` on the `wasm32-wasi*` targets)
 - rust-lang/rust#149885 (replace addr_of_mut with &raw mut in maybeuninit docs)
 - rust-lang/rust#149949 (Cleanup of attribute parsing errors)
 - rust-lang/rust#149969 (don't use no_main and no_core to test IBT)
 - rust-lang/rust#149998 (miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
@alexcrichton alexcrichton deleted the wasi-avoid-linkat branch December 22, 2025 21:17
bors added a commit that referenced this pull request Dec 23, 2025
std: Use `usleep` temporarily on WASI targets

This fixes some fallout from #147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to #149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release.

Closes #150290
Kobzol pushed a commit to Kobzol/rustc_codegen_cranelift that referenced this pull request Dec 23, 2025
std: Use `usleep` temporarily on WASI targets

This fixes some fallout from rust-lang/rust#147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to rust-lang/rust#149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release.

Closes rust-lang/rust#150290
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Dec 24, 2025
std: Use `usleep` temporarily on WASI targets

This fixes some fallout from rust-lang/rust#147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to rust-lang/rust#149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release.

Closes rust-lang/rust#150290
github-actions bot pushed a commit to rust-lang/rust-analyzer that referenced this pull request Dec 25, 2025
std: Use `usleep` temporarily on WASI targets

This fixes some fallout from rust-lang/rust#147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to rust-lang/rust#149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release.

Closes rust-lang/rust#150290
rust-bors bot pushed a commit that referenced this pull request Feb 6, 2026
Update wasi-sdk used in CI/releases

This is similar to prior updates such as #149037 in that this is just updating a URL. This update though has some technical updates accompanying it as well, however:

* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this target, even for startup. This means that the final binary no longer has an "adapter" which can help making instantiation of a component a bit more lean.

* In #147572 libstd was updated to use wasi-libc more often on the `wasm32-wasip2` target. This uncovered a number of bugs in wasi-libc such as #149864, #150291, and #151016. These are all fixed in wasi-sdk-30 so the workarounds in the standard library are all removed.

Overall this is not expected to have any sort of major impact on users of WASI targets. Instead it's expected to be a normal routine update to keep the wheels greased and oiled.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants