Skip to content
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

Make the wasm and wasm64 modules unstable #1247

Merged
merged 1 commit into from
Nov 5, 2021

Conversation

Amanieu
Copy link
Member

@Amanieu Amanieu commented Nov 5, 2021

Tracking issue: rust-lang/rust#90599

@rust-highfive
Copy link

@Amanieu: no appropriate reviewer found, use r? to override

@Amanieu
Copy link
Member Author

Amanieu commented Nov 5, 2021

cc @devsnek @alexcrichton

@devsnek
Copy link
Contributor

devsnek commented Nov 5, 2021

seems legit

@Amanieu Amanieu merged commit 8a5358c into rust-lang:master Nov 5, 2021
@Amanieu Amanieu deleted the wasm64_unstable branch November 5, 2021 02:50
@alexcrichton
Copy link
Member

Personally I don't think that the wasm64 module should be unstable. All of the intrinsics were designed for wasm64 (e.g. usize/pointers instead of i32/etc) and it follows well-established conventions of module-named-after-target_arch. The target itself is still only available via -Zbuild-std which gives it more time to bake on nightly.

@Amanieu
Copy link
Member Author

Amanieu commented Nov 5, 2021

I would like to resolve the issue of whether to have a generic wasm module.

@alexcrichton
Copy link
Member

While I understand that wasm is "under construction", making wasm64 nightly-only in the meantime only serves to arbitrarily make experimentation with wasm64 harder than it otherwise would be. Can wasm64 not require a feature gate and if necessary this is revisited before providing a rustup-installable-component?

@Amanieu
Copy link
Member Author

Amanieu commented Nov 6, 2021

As a general rule we don't add any stable APIs to the standard library without going through an FCP first. I personally don't think adding wasm64 is too controversial since we already have wasm32 stable. However I think the common wasm module may be more controversial. This should be discussed in the tracking issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants