bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

Address review comments on wasm32v1-none target

Browse source
This commit is contained in:
Graydon Hoare 2024-10-16 16:48:53 -07:00
parent e14d6d8314
commit 212d516ab0
No known key found for this signature in database
GPG key ID: 69824B014EE65219
6 changed files with 126 additions and 50 deletions
Download patch file Download diff file Expand all files Collapse all files

63
compiler/rustc_target/src/spec/targets/wasm32v1_none.rs
View file

@ -1,55 +1,16 @@
//! A "bare wasm" target representing a WebAssembly output that makes zero
//! assumptions about its environment, similar to wasm32-unknown-unknown, but
//! that also specifies an _upper_ bound on the set of wasm proposals that are
//! supported.
//! A "bare wasm" target representing a WebAssembly output that does not import
//! anything from its environment and also specifies an _upper_ bound on the set
//! of WebAssembly proposals that are supported.
//!
//! It is implemented as a variant on LLVM's wasm32-unknown-unknown target, with
//! the additional flags `-Ctarget-cpu=mvp` and `-Ctarget-feature=+mutable-globals`.
//!
//! This target exists to resolve a tension in Rustc's choice of WebAssembly
//! proposals to support. Since most WebAssembly users are in fact _on the web_
//! and web browsers are frequently updated with support for the latest
//! features, it is reasonable for Rustc to generate wasm code that exploits new
//! WebAssembly proposals as they gain browser support. At least by default. And
//! this is what the wasm32-unknown-unknown target does, which means that the
//! _exact_ WebAssembly features that Rustc generates will change over time.
//!
//! But a different set of users -- smaller but nonetheless worth supporting --
//! are using WebAssembly in implementations that either don't get updated very
//! often, or need to prioritize stability, implementation simplicity or
//! security over feature support. This target is for them, and it promises that
//! the wasm code it generates will not go beyond the proposals/features of the
//! W3C WebAssembly core 1.0 spec, which (as far as I can tell) is approximately
//! "the wasm MVP plus mutable globals". Mutable globals was proposed in 2018
//! and made it in.
//!
//! See https://www.w3.org/TR/wasm-core-1/
//!
//! Notably this feature-set _excludes_:
//!
//! - sign-extension operators
//! - non-trapping / saturating float-to-int conversions
//! - multi-value
//! - reference types
//! - bulk memory operations
//! - SIMD
//!
//! These are all listed as additions in the core 2.0 spec. Also they were all
//! proposed after 2020, and core 1.0 shipped in 2019. It also excludes even
//! later proposals such as:
//!
//! - exception handling
//! - tail calls
//! - extended consts
//! - function references
//! - multi-memory
//! - component model
//! - gc
//! - threads
//! - relaxed SIMD
//! - custom annotations
//! - branch hinting
//! It's equivalent to the `wasm32-unknown-unknown` target with the additional
//! flags `-Ctarget-cpu=mvp` and `-Ctarget-feature=+mutable-globals`. This
//! enables just the features specified in <https://www.w3.org/TR/wasm-core-1/>
//!
//! This is a _separate target_ because using `wasm32-unknown-unknown` with
//! those target flags doesn't automatically rebuild libcore / liballoc with
//! them, and in order to get those libraries rebuilt you need to use the
//! nightly Rust feature `-Zbuild-std`. This target is for people who want to
//! use stable Rust, and target a stable set pf WebAssembly features.
use crate::spec::{Cc, LinkerFlavor, Target, base};
@ -57,6 +18,8 @@ pub(crate) fn target() -> Target {
let mut options = base::wasm::options();
options.os = "none".into();
// WebAssembly 1.0 shipped in 2019 and included exactly one proposal
// after the initial "MVP" feature set: "mutable-globals".
options.cpu = "mvp".into();
options.features = "+mutable-globals".into();