Skip to content

Commit 4a72d62

Browse files
committed
Reword/clarify section on ABIs
1 parent 50ce531 commit 4a72d62

File tree

1 file changed

+18
-10
lines changed

1 file changed

+18
-10
lines changed

posts/2024-08-26-webassembly-targets-change-in-default-target-features.md

+18-10
Original file line numberDiff line numberDiff line change
@@ -170,10 +170,14 @@ from suitably motivated contributors.
170170
### Aside: ABI Stability and WebAssembly
171171

172172
While on the topic of ABIs and the `multivalue` feature it's perhaps worth
173-
also going over a bit what ABIs mean for WebAssembly. Currently there's
174-
effectively only one ABI implemented by LLVM and the Rust compiler meaning that
175-
at the WebAssembly module level `extern "C"` and `extern "Rust"` are
176-
more-or-less the same. It is **not** guaranteed for the ABIs to match, however.
173+
also going over a bit what ABIs mean for WebAssembly. The current definition of
174+
the `extern "C"` ABI for WebAssembly is documented in the [tool-conventions
175+
repository](https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md)
176+
and this is what Clang implements for C code as well. LLVM implements enough
177+
support for lowering to WebAssembly as well to support all of this. The `extern
178+
"Rust` ABI is not stable on WebAssembly, as is the case for all Rust targets,
179+
and is subject to change over time. There is no reference documentation at this
180+
time for what `extern "Rust"` is on WebAssembly.
177181

178182
The `extern "C"` ABI, what C code uses by default as well, is difficult to
179183
change because stability is often required across different compiler versions.
@@ -182,17 +186,21 @@ with code compiled by LLVM 20. This means that changing the ABI is a daunting
182186
task that requires version fields, explicit markers, etc, to help prevent
183187
mismatches.
184188

185-
The `extern "Rust"` ABI, however, is entirely within the control of the Rust
186-
compiler and can change from version to version (there are no stability
187-
guarantees across compiler versions and this is applicable to all platforms, not
188-
just WebAssembly). Just because `extern "Rust"` happens to work like `extern
189-
"C"` in WebAssembly today doesn't mean it will continue to do so in the future.
190-
A great example of this is that when the `multivalue` feature is enabled the
189+
The `extern "Rust"` ABI, however, is subject to change over time. A great
190+
example of this could be that when the `multivalue` feature is enabled the
191191
`extern "Rust"` ABI could be redefined to use the multiple-return-values that
192192
WebAssembly would then support. This would enable much more efficient returns
193193
of values larger than 64-bits. Implementing this would require support in LLVM
194194
though which is not currently present.
195195

196+
This all means that actually using multiple-returns in functions, or the
197+
WebAssembly feature that the `multivalue` enables, is still out on the horizon
198+
and not implemented. First LLVM will need to implement complete lowering support
199+
to generate WebAssembly functions with multiple returns, and then `extern
200+
"Rust"` can be change to use this when fully supported. In the yet-further-still
201+
future C code might be able to change, but that will take quite some time due to
202+
its cross-version-compatibility story.
203+
196204
## Enabling Future Proposals to WebAssembly
197205

198206
This is not the first time that a WebAssembly proposal has gone from

0 commit comments

Comments
 (0)