Remove nonexistent clocks on WASI by alexcrichton · Pull Request #4880 · rust-lang/libc

alexcrichton · 2025-12-10T21:30:06Z

These were added way back when in #2499 and while they may have existed in a historical version of wasi-libc they most certainly do not exist in the current wasi-libc. Any usage of them is already-breaking, so this deletes these items.

These were added way back when in rust-lang#2499 and while they may have existed in a historical version of wasi-libc they most certainly do not exist in the current wasi-libc. Any usage of them is already-breaking, so this deletes these items.

alexcrichton · 2025-12-10T22:10:08Z

This is something I'd ideally like to backport to the 0.2 version as well, although naturally it's a strictly-speaking breaking change. Technically historical changes like ca20d7d were also breaking in a minor fashion too, but this in theory could have higher impact because it's a more C-like constant rather than something libc-specific.

Basically I don't know what the fallout of this would be. Extrapolating the highest risk is a crate that uses these constants in platform-specific code, including WASI, but the code is dead at runtime so no one noticed that it wouldn't work if it were executed. I'm not sure how prevalent such a situation is, however.

tgross35

Thanks! I think this is fine to backport if you're okay with it: my philosophy has basically been that for anything in boat of "technically breaking but anybody using this is already broken without knowing it", it's more useful to poke users to fix the broken code than it is to spend effort keeping things half-working. At least on T<=2 platforms and more niche API. From your description, I think that applies here.

alexcrichton · 2025-12-18T16:48:14Z

Sounds good to me! And yeah I'm comfortable backporting this myself, and feel free to redirect any confusion to me if you happen to see it

These were added way back when in rust-lang#2499 and while they may have existed in a historical version of wasi-libc they most certainly do not exist in the current wasi-libc. Any usage of them is already-breaking, so this deletes these items. (backport <rust-lang#4880>) (cherry picked from commit e883afc)

These were added way back when in #2499 and while they may have existed in a historical version of wasi-libc they most certainly do not exist in the current wasi-libc. Any usage of them is already-breaking, so this deletes these items. (backport <#4880>) (cherry picked from commit e883afc)

…ed, r=Mark-Simulacrum rustc: Stop passing `--allow-undefined` on wasm targets This commit updates how the linker is invoked on WebAssembly targets (all of them) to avoid passing the `--allow-undefined` flag to the linker. Historically, if I remember this correctly, when `wasm-ld` was first integrated this was practically required because at the time it was otherwise impossible to import a function from the host into a wasm binary. Or, at least, I'm pretty sure that was why this was added. At the time, as the documentation around this option indicates, it was known that this was going to be a hazard. This doesn't match behavior on native, for example, and can easily paper over what should be a linker error with some sort of other obscure runtime error. An example is that this program currently compiles and links, it just prints null: unsafe extern "C" { static nonexistent: u8; } fn main() { println!("{:?}", &raw const nonexistent); } This can easily lead to mistakes like rust-lang/libc#4880 and defer what should be a compile-time link error to weird or unusual behavior at link time. Additionally, in the intervening time since `wasm-ld` was first introduced here, lots has changed and notably this program works as expected: #[link(wasm_import_module = "host")] unsafe extern "C" { fn foo(); } fn main() { unsafe { foo(); } } This continues to compile without error and the final wasm binary indeed has an imported function from the host. This program: unsafe extern "C" { fn foo(); } fn main() { unsafe { foo(); } } this currently compiles successfully and emits an import from the `env` module. After this change, however, this will fail to compile with a link error stating that the `foo` symbol is not defined.

Rollup merge of #149868 - alexcrichton:wasm-no-allow-undefined, r=Mark-Simulacrum rustc: Stop passing `--allow-undefined` on wasm targets This commit updates how the linker is invoked on WebAssembly targets (all of them) to avoid passing the `--allow-undefined` flag to the linker. Historically, if I remember this correctly, when `wasm-ld` was first integrated this was practically required because at the time it was otherwise impossible to import a function from the host into a wasm binary. Or, at least, I'm pretty sure that was why this was added. At the time, as the documentation around this option indicates, it was known that this was going to be a hazard. This doesn't match behavior on native, for example, and can easily paper over what should be a linker error with some sort of other obscure runtime error. An example is that this program currently compiles and links, it just prints null: unsafe extern "C" { static nonexistent: u8; } fn main() { println!("{:?}", &raw const nonexistent); } This can easily lead to mistakes like rust-lang/libc#4880 and defer what should be a compile-time link error to weird or unusual behavior at link time. Additionally, in the intervening time since `wasm-ld` was first introduced here, lots has changed and notably this program works as expected: #[link(wasm_import_module = "host")] unsafe extern "C" { fn foo(); } fn main() { unsafe { foo(); } } This continues to compile without error and the final wasm binary indeed has an imported function from the host. This program: unsafe extern "C" { fn foo(); } fn main() { unsafe { foo(); } } this currently compiles successfully and emits an import from the `env` module. After this change, however, this will fail to compile with a link error stating that the `foo` symbol is not defined.

…k-Simulacrum rustc: Stop passing `--allow-undefined` on wasm targets This commit updates how the linker is invoked on WebAssembly targets (all of them) to avoid passing the `--allow-undefined` flag to the linker. Historically, if I remember this correctly, when `wasm-ld` was first integrated this was practically required because at the time it was otherwise impossible to import a function from the host into a wasm binary. Or, at least, I'm pretty sure that was why this was added. At the time, as the documentation around this option indicates, it was known that this was going to be a hazard. This doesn't match behavior on native, for example, and can easily paper over what should be a linker error with some sort of other obscure runtime error. An example is that this program currently compiles and links, it just prints null: unsafe extern "C" { static nonexistent: u8; } fn main() { println!("{:?}", &raw const nonexistent); } This can easily lead to mistakes like rust-lang/libc#4880 and defer what should be a compile-time link error to weird or unusual behavior at link time. Additionally, in the intervening time since `wasm-ld` was first introduced here, lots has changed and notably this program works as expected: #[link(wasm_import_module = "host")] unsafe extern "C" { fn foo(); } fn main() { unsafe { foo(); } } This continues to compile without error and the final wasm binary indeed has an imported function from the host. This program: unsafe extern "C" { fn foo(); } fn main() { unsafe { foo(); } } this currently compiles successfully and emits an import from the `env` module. After this change, however, this will fail to compile with a link error stating that the `foo` symbol is not defined.

Remove nonexistent clocks on WASI

d857833

These were added way back when in rust-lang#2499 and while they may have existed in a historical version of wasi-libc they most certainly do not exist in the current wasi-libc. Any usage of them is already-breaking, so this deletes these items.

rustbot added O-wasi S-waiting-on-review labels Dec 10, 2025

alexcrichton mentioned this pull request Dec 10, 2025

rustc: Stop passing --allow-undefined on wasm targets rust-lang/rust#149868

Merged

tgross35 approved these changes Dec 17, 2025

View reviewed changes

tgross35 added this pull request to the merge queue Dec 17, 2025

tgross35 added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Dec 17, 2025

Merged via the queue into rust-lang:main with commit e883afc Dec 17, 2025
50 of 51 checks passed

rustbot removed the S-waiting-on-review label Dec 17, 2025

alexcrichton deleted the remove-some-wasi-things branch December 18, 2025 16:47

tgross35 mentioned this pull request Jan 3, 2026

[0.2] Backports #4898

Merged

tgross35 added stable-applied This PR has been cherry-picked to libc's stable release branch and removed stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Jan 3, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove nonexistent clocks on WASI#4880

Remove nonexistent clocks on WASI#4880
tgross35 merged 1 commit intorust-lang:mainfrom
alexcrichton:remove-some-wasi-things

alexcrichton commented Dec 10, 2025 •

edited by rustbot

Loading

Uh oh!

alexcrichton commented Dec 10, 2025

Uh oh!

tgross35 left a comment

Uh oh!

Uh oh!

alexcrichton commented Dec 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

alexcrichton commented Dec 10, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexcrichton commented Dec 10, 2025

Uh oh!

tgross35 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alexcrichton commented Dec 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

alexcrichton commented Dec 10, 2025 •

edited by rustbot

Loading