Introduce perma-unstable `wasm-c-abi` flag by daxpedda · Pull Request #117919

Introduce perma-unstable `wasm-c-abi` flag by daxpedda · Pull Request #117919 · rust-lang/rust

rustbot added S-waiting-on-review

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

T-compiler

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

labels

Nov 14, 2023

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

Apr 18, 2024

Introduce perma-unstable `wasm-c-abi` flag

Now that `wasm-bindgen` v0.2.88 supports the spec-compliant C ABI, the idea is to switch to that in a future version of Rust. In the meantime it would be good to let people test and play around with it.

This PR introduces a new perma-unstable `-Zwasm-c-abi` compiler flag, which switches to the new spec-compliant C ABI when targeting `wasm32-unknown-unknown`.

Alternatively, we could also stabilize this and then deprecate it when we switch. I will leave this to the Rust maintainers to decide.

This is a companion PR to rust-lang#117918, but they could be merged independently.
MCP: rust-lang/compiler-team#703
Tracking issue: rust-lang#122532

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Apr 18, 2024

Introduce perma-unstable `wasm-c-abi` flag

Now that `wasm-bindgen` v0.2.88 supports the spec-compliant C ABI, the idea is to switch to that in a future version of Rust. In the meantime it would be good to let people test and play around with it.

This PR introduces a new perma-unstable `-Zwasm-c-abi` compiler flag, which switches to the new spec-compliant C ABI when targeting `wasm32-unknown-unknown`.

Alternatively, we could also stabilize this and then deprecate it when we switch. I will leave this to the Rust maintainers to decide.

This is a companion PR to rust-lang#117918, but they could be merged independently.
MCP: rust-lang/compiler-team#703
Tracking issue: rust-lang#122532

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

Apr 18, 2024

…kingjubilee

Rollup of 6 pull requests

Successful merges:

 - rust-lang#117919 (Introduce perma-unstable `wasm-c-abi` flag)
 - rust-lang#123571 (Correctly change type when adding adjustments on top of `NeverToAny`)
 - rust-lang#123752 (Properly handle emojis as literal prefix in macros)
 - rust-lang#123980 ( Add an opt-in to store incoming edges in `VecGraph` + misc)
 - rust-lang#124110 (Fix negating `f16` and `f128` constants)
 - rust-lang#124116 (when suggesting RUST_BACKTRACE=1, add a special note for Miri's env var isolation)

r? `@ghost`
`@rustbot` modify labels: rollup

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Apr 18, 2024

Introduce perma-unstable `wasm-c-abi` flag

Now that `wasm-bindgen` v0.2.88 supports the spec-compliant C ABI, the idea is to switch to that in a future version of Rust. In the meantime it would be good to let people test and play around with it.

This PR introduces a new perma-unstable `-Zwasm-c-abi` compiler flag, which switches to the new spec-compliant C ABI when targeting `wasm32-unknown-unknown`.

Alternatively, we could also stabilize this and then deprecate it when we switch. I will leave this to the Rust maintainers to decide.

This is a companion PR to rust-lang#117918, but they could be merged independently.
MCP: rust-lang/compiler-team#703
Tracking issue: rust-lang#122532

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

Apr 19, 2024

…kingjubilee

Rollup of 9 pull requests

Successful merges:

 - rust-lang#117919 (Introduce perma-unstable `wasm-c-abi` flag)
 - rust-lang#123406 (Force exhaustion in iter::ArrayChunks::into_remainder)
 - rust-lang#123752 (Properly handle emojis as literal prefix in macros)
 - rust-lang#123935 (Don't inline integer literals when they overflow - new attempt)
 - rust-lang#123980 ( Add an opt-in to store incoming edges in `VecGraph` + misc)
 - rust-lang#124019 (Use raw-dylib for Windows synchronization functions)
 - rust-lang#124110 (Fix negating `f16` and `f128` constants)
 - rust-lang#124112 (Fix ICE when there is a non-Unicode entry in the incremental crate directory)
 - rust-lang#124116 (when suggesting RUST_BACKTRACE=1, add a special note for Miri's env var isolation)

r? `@ghost`
`@rustbot` modify labels: rollup

bors mentioned this pull request

Apr 19, 2024

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

Jul 10, 2024

Introduce perma-unstable `wasm-c-abi` flag

Now that `wasm-bindgen` v0.2.88 supports the spec-compliant C ABI, the idea is to switch to that in a future version of Rust. In the meantime it would be good to let people test and play around with it.

This PR introduces a new perma-unstable `-Zwasm-c-abi` compiler flag, which switches to the new spec-compliant C ABI when targeting `wasm32-unknown-unknown`.

Alternatively, we could also stabilize this and then deprecate it when we switch. I will leave this to the Rust maintainers to decide.

This is a companion PR to rust-lang#117918, but they could be merged independently.
MCP: rust-lang/compiler-team#703
Tracking issue: rust-lang#122532

nikic mentioned this pull request

Jul 10, 2024

warpfork added a commit to warpfork/datamaps that referenced this pull request

Dec 7, 2024

This... finally breaks down and requires rust nightly.
I've been going to considerable lengths to try to avoid this, but...
I earnestly don't think shipping C+Rust to wasm is possible without it.

The main new thing here is the "-Zwasm-c-abi=spec" flag.
As described in the README diff, it's essential for rust to call
into C correctly when both are wasm'd.

(It's beyond me why any other mode exists, but I'll... attempt to bite
my tongue.)

This critical flag was introduced in
rust-lang/rust#117919 .

Which describes it as "perma-unstable".  And gosh I hope that's not
actually going to be true... because again, this seems to be flat out
*required* for Rust and C to play together in wasm.  And also because
"perma-unstable" is just a deeply silly concept, period, context-free.

I do not understand any possible reason to want to push people
*permanently* towards using "unstable" "nightly" compilers.
I don't understand how this needs to be said, but creating a situation
where the words "permanently unstable" go together is a Bad Idea.

Anyway.

The "target-feature=+bulk-memory" flag also comes along because without
that, we get a "Uncaught RangeError: Maximum call stack size exceeded"
error at runtime.  It's attributed to
"core::intrinsics::copy::precondition_check" called from "memmove".
(That doesn't make a ton of sense to me, looking at the code, but...
a lot of things don't make sense to me, looking at any of this; add
it to the pile.)  Whatever the reason, this flag makes it go.

And now it's alive.

It's taken days.  But hello world has landed.  Hooray.