Add wasm32v1-none target (compiler-team/#791) by graydon · Pull Request #131487 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation44 Commits4 Checks6 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

graydon

This is a preliminary implementation of the MCP discussed in compiler-team#791. It's not especially "major" but you know, process! Anyway it adds a new wasm32v1-none target which just pins down a set of wasm features. I think this is close to the consensus that emerged when discussing it on Zulip so I figured I'd sketch to see how hard it is. Turns out not very.

@rustbot

r? @Nadrieril

rustbot has assigned @Nadrieril.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot 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

Oct 10, 2024

Urgau

jieyouxu

@rust-log-analyzer

This comment has been minimized.

alexcrichton

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Nadrieril

@graydon graydon marked this pull request as ready for review

October 16, 2024 23:57

@rustbot

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

These commits modify compiler targets.
(See the Target Tier Policy.)

@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added A-testsuite

Area: The testsuite used to check the correctness of rustc

T-infra

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

labels

Oct 17, 2024

alexcrichton

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops sorry I wrote these comments last week but forgot to hit submit...

Otherwise though the MCP has now finished so with this it looks good to me and would be happy to approve.

$ rustc -target wasm32v1-none
```
The difference is in how the `core` and `alloc` crates are compiled for distribution with the toolchain, and whether it works on _stable_ Rust toolchains or requires _nightly_ ones. Again referring back to the [`wasm32-unknown-unknown` document](./wasm32-unknown-unknown.md), note that to disable all post-MVP proposals on that target one _actually_ has to compile with this:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're feeling up for it (optional as I'm happy to do this later too), mind updating the docs in wasm32-unknown-unknown.md with respect to this new target? For example the documentation can indicate how to disable default features both with -Zbuild-std but also referring to this target primarily. The -Zbuild-std bits aren't really need any more unless you really want the standard library of wasm32-unknown-unknown which is probably unlikely.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add a note, but I think the build-std part needs to stay if you're targeting MVP and not MVP+mutable-globals as the wasm32v1 target supplies. Or if you need std.

leighmcculloch

@@ -1803,6 +1803,7 @@ supported_targets! {
("wasm32-unknown-emscripten", wasm32_unknown_emscripten),
("wasm32-unknown-unknown", wasm32_unknown_unknown),
("wasm32v1-none", wasm32v1_none),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the way to cfg on this specific target be to specify:

#[cfg(all(target_family = "wasm", target_os = "none"))]

or

#[cfg(all(target_arch = "wasm32", target_os = "none"))]

If in the future a wasm32v2-none is released, how will it be distinguished in a cfg?

Or will the target_arch be wasm32v1 and in the future wasm32v2?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just differentiate them through the target features.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW the documentation in this PR has an answer to your original question:

It's recommended to conditionally compile code for this target with:

#[cfg(all(target_family = "wasm", target_os = "none"))]

Otherwise I would also agree with @CryZe. All other native platforms have a constant target_arch string with a variable target_feature set corresponding to levels of support for various features.

The situation you're referring to where multivalue and reference-types aren't stable right now isn't an issue for this target. This'll be a new target when it lands and users should also be able to see multivalue and reference-types when they get to use it since that PR should land relatively soon as well.

Stabilization of wasm features has lagged behind for awhile and this is basically good motivation to ensure we keep up in the future. For example another option is blocking a hypothetical wasm32v2-none target until all of the features it enables are landed and stable in Rust. (or, for example, blocking this PR on #131080 but to be clear I'm not advocating we do that)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the target_env be set to v1 or v2?

For example, the following cfg to unambiguously distinguish the target:

#[cfg(all(target_arch = "wasm32", target_env = "v1", target_os = "none"))]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As Alex said: The incentive structure that encourages people to push for stabilizing a target feature name that is well-defined, so that we can e.g. evaluate it for its ABI impacts, is intentional.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what @leighmcculloch is looking for is a way to make a cfg check that specifically identifies the condition of "being limited to the features in wasm32v1-none". Like he wants to not detect any specific new features, but detect the absence of all new features, including features not-yet-invented. Because that's the only case we want to compile for. We want to emit an error if the user tries to build for a target that enables any further wasm features. Which -- even if the current set of feature names all stabilize -- he can't write code to detect because they don't exist yet.

If there were -- speaking hypothetically -- some way to say cfg(target_triple="wasm32v1-none") or even cfg(target_subarch="wasm32v1") that would do the trick. Or anything else that pins to this subarch version and not future versions. I'm not sure if there's a good way to make that happen with the tools currently available though.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe there is nonesuch in "ways to conveniently do that", yes.

The answer, however, is cfg(target_feature = "nontrapping-fptoint"), or the cfg(not()) version.

The reason that will work is that feature was specifically added for Rust, and it is part of the v2 definition, so "post v1" Rust targets simply will not ever exclude it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you're asking for "and no 'manual' use of any target_feature anywhere, either", which is:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhm. Thanks. I'm sure we'll figure out some not-so-bad guardrails that handle the majority of cases.

@alexcrichton

@bors

📌 Commit b0f0282 has been approved by alexcrichton

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

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

labels

Oct 23, 2024

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

Oct 23, 2024

@bors

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

Oct 23, 2024

@rust-timer

Rollup merge of rust-lang#131487 - graydon:wasm32v1-none, r=alexcrichton

Add wasm32v1-none target (compiler-team/rust-lang#791)

This is a preliminary implementation of the MCP discussed in compiler-team#791. It's not especially "major" but you know, process! Anyway it adds a new wasm32v1-none target which just pins down a set of wasm features. I think this is close to the consensus that emerged when discussing it on Zulip so I figured I'd sketch to see how hard it is. Turns out not very.

@danielhjacobs

We're thinking of switching to this target in our code-base once it reaches stable, but another developer had questions.

and, if any/all of these are false:

The code-base, for reference, is https://github.com/ruffle-rs/ruffle. I'll also add that we prefer to do everything with stable Rust.

@danielhjacobs

In testing, I got these errors:

error[E0463]: can't find crate for `core`
  |
  = note: the `wasm32-unknown-unknown` target may not be installed
  = help: consider downloading the target with `rustup target add wasm32-unknown-unknown`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `cfg-if` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error[E0463]: can't find crate for `std`
  |
  = note: the `wasm32-unknown-unknown` target may not be installed
  = help: consider downloading the target with `rustup target add wasm32-unknown-unknown`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

@alexcrichton

@danielhjacobs there's no std, so no Mutex or Path or Duration. There's no means by which to re-enable std for this target unless you're using -Zbuild-std, at which point you can also use wasm32-unknown-unknown.

For the build error, I think that's still something using --target wasm32-unknown-unknown which needs to switch to wasm32v1-none, but if you need std to work then this target won't work for you

@danielhjacobs

Hi Alex. That's unfortunate, we were hoping to keep Ruffle working on Pale Moon and on old versions of Safari before the reference types proposal was supported. We can't do that without pinning to Rust 1.81.0 or using nightly Rust, which we don't want to do. rustwasm/wasm-bindgen#4213 will cause wasm-bindgen to at least generate JS glue code that doesn't use those features, but the statement that "For the reference-types feature the encoding of immediates in the call_indirect, a commonly used instruction by the WebAssembly backend, has changed. Validators and parsers which don't understand the reference-types proposal will no longer accept modules produced by LLVM due to this change in encoding of immediates." makes me wary Ruffle will work on those browsers even after that wasm-bindgen PR is out in a new release.

@danielhjacobs

I assume there's no chance to get a target like this but which builds std?

Note that I think I fixed the references to wasm32-unknown-unknown and now I'm getting these errors:

message.txt

@leighmcculloch

error[E0463]: can't find crate for core

Does this mean core is also unavailable on this target?

@danielhjacobs

@workingjubilee

I assume there's no chance to get a target like this but which builds std?

Probably Not. We do not really want to entertain another target that has a standard library as busted as wasm32-unknown-unknown's is.

but the statement that "For the reference-types feature the encoding of immediates in the call_indirect, a commonly used instruction by the WebAssembly backend, has changed. Validators and parsers which don't understand the reference-types proposal will no longer accept modules produced by LLVM due to this change in encoding of immediates." makes me wary Ruffle will work on those browsers even after that wasm-bindgen PR is out in a new release.

Using this target, plus the relevant wasm tooling with that "don't enable externref automatically" PR merged, should generate correct code for your use-case that is recognized by Pale Moon and old Safari.

The errors in the log you showed are from using crates with features enabled that cause them to not support no_std. As the once_cell crate supports using it on no_std, and I did not see any direct dependencies on it in your tree's Cargo.tomls, it is the result of other crates you depend on.

@danielhjacobs

@workingjubilee

tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request

Jan 22, 2025

@tmeijn

This MR contains the following updates:

Package Update Change
rust minor 1.83.0 -> 1.84.0

MR created with the help of el-capitano/tools/renovate-bot.

Proposed changes to behavior should be submitted there as MRs.

Release Notes

rust-lang/rust (rust)

v1.84.0

Compare Source

==========================

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts

Cargo

Rustdoc

Compatibility Notes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

This MR has been generated by Renovate Bot.

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

Feb 2, 2025

@he32

Pkgsrc changes:

Upstream changes:

Version 1.84.1 (2025-01-30)

Version 1.84.0 (2025-01-09)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts

Cargo

Rustdoc

Compatibility Notes

Labels

A-testsuite

Area: The testsuite used to check the correctness of rustc

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-compiler

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

T-infra

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