-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expose wasm
intrinsics using target_family = "wasm"
#1241
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) soon. Please see the contribution instructions for more information. |
thanks! |
Personally I don't think that this should happen. Even x86/x86_64 don't have precedent for this which is my main personal rationale, but otherwise this is also a new insta-stable module (which I'm not sure was intended?) |
Oh whoops, I missed the fact that this was marked as insta-stable. |
x86 and x86_64 have a different instruction set. wasm32 and wasm64 use the exact same instruction set. AFAIK it is even possible to get a mix of the two by having more than one linear memory. LLVM currently doesn't support this AFAIK, but it could by using different address space's for each linear memory. |
This is causing a problem for wasm32-unknown-emscripten which is in the |
It sounds more like emscripten should be in that family instead to me. It looks like emscripten accidentally overwrites the families here instead of appending to the wasm base's families: https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/wasm32_unknown_emscripten.rs#L40 |
@ehuss looks like the failure came through at rust-lang/rust#90382 (comment), I added another commit to add |
I think it should be idiomatic to use
target_family = "wasm"
instead oftarget_arch = "wasmNN"
, so we encourage the ecosystem to write code that works for both. This makes it easier to do that by exporting awasm
in addition towasm32
andwasm64
.