-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Stabilize Wasm target features that are in phase 4 and 5 #117457
Conversation
r? @cjgillot (rustbot has picked a reviewer for you, use r? to override) |
Cc @alexcrichton. |
AFAIK a stabilization policy is not documented anywhere for WebAssembly target features, but in my opinion this is a good PR to land. As a bit of background on this in case anyone's curious: WebAssembly target features in LLVM relate to WebAssembly proposals and are frequently named after those proposals. WebAssembly proposals go through a phased design process similar to JS and once a feature reaches "phase 4" it's effectively done and ready for everyone to use. That's when browsers start shipping the feature ungated for example. There is no "standard" for what to call these proposals beyond "toolchain conventions" which, at this time, is "whatever LLVM called it". In that sense the choice of feature name here matches what one would use on the command line for C/C++ when compiling WebAssembly. This particular proposal, along with others, as pointed out, is "stage 5" which means it's long since done and overdue for stabilization on our end. |
@alexcrichton do you mind taking the review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certainly! I fear I may not have bors permissions any more though, but I can offer a github approval nonetheless
nontrapping-fptoint
3c77937
to
5d0e1c9
Compare
I decided to add the remaining features into the same PR as they don't require any further work in the Rust compiler. |
@alexcrichton can you clarify the impact of stabilizing these items? What impact does it have on what Rust code people are allowed to write? Do these affect the quality of codegen only? Does that imply that a broader set of Rust code will compile on the wasm target? How do people specify which target features they want to be using? I'm generally in favor of doing this, but it would be good to understand what exactly it means. |
In particular I am also trying to figure out if this is T-compiler, T-lang, or both in terms of who needs to commit to stabilization. |
@rfcbot fcp merge I am going to assume that this is both a lang and compiler RFC, and hence I move to merge, based on what @alexcrichton had to say here. Here is my understanding of what we are stabilizing:
The primary concern I can imagine, if the above is correct, is that the compiler doesn't handle the flags correctly or that this may allow some Rust code to reach WASM that "ought not to" (not sure how that latter part would happen though unless there was a bug somewhere else in rustc that enabled it, so i.e. the first problem). |
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
I assume this would include the ability to specify those features in both compiler flags and Also @nikomatsakis it sounds like the exact names being used actually come from LLVM. I don't see any reason to differ on those though. In any case this all sounds fine to me, so @rfcbot reviewed |
Sure yeah I can try to document and clarify a few things here. I'll reiterate For background here the WebAssembly Community Group (CG) is the main technical Proposals which have reached at least stage 4 are generally considered done. At All of the features stabilized here are phase 4 and beyond (many at phase 5). Ok so how does any of this affect Rust. Rust supports compilation to WebAssembly
So given all that, this PR largely boils down to enabling
|
|
I'm going to rubber stamp this if wasm experts are on board with this stabilization. |
☔ The latest upstream changes (presumably #117915) made this pull request unmergeable. Please resolve the merge conflicts. |
5d0e1c9
to
cc18845
Compare
☔ The latest upstream changes (presumably #118957) made this pull request unmergeable. Please resolve the merge conflicts. |
cc18845
to
7f7454d
Compare
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
1d46f00
to
07c2e62
Compare
Some changes occurred in tests/ui/check-cfg cc @Urgau |
@wesleywiser apologies for the delay. |
☔ The latest upstream changes (presumably #124026) made this pull request unmergeable. Please resolve the merge conflicts. |
07c2e62
to
638f541
Compare
☔ The latest upstream changes (presumably #124111) made this pull request unmergeable. Please resolve the merge conflicts. |
638f541
to
6a52fee
Compare
@bors r=wesleywiser |
☀️ Test successful - checks-actions |
Finished benchmarking commit (b9be3c4): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 672.201s -> 671.949s (-0.04%) |
Stabilize Wasm target features that are in phase 4 and 5 This stabilizes the Wasm target features that are known to be working and in [phase 4 and 5](https://github.com/WebAssembly/proposals/tree/04fa8c810e1dc99ab399e41052a6e427ee988180). Feature stabilized: - [Non-trapping float-to-int conversions](https://github.com/WebAssembly/nontrapping-float-to-int-conversions) - [Import/Export of Mutable Globals](https://github.com/WebAssembly/mutable-global) - [Sign-extension operators](https://github.com/WebAssembly/sign-extension-ops) - [Bulk memory operations](https://github.com/WebAssembly/bulk-memory-operations) - [Extended Constant Expressions](https://github.com/WebAssembly/extended-const) Features not stabilized: - [Multi-value](https://github.com/WebAssembly/multi-value): requires rebuilding `std` #73755. - [Reference Types](https://github.com/WebAssembly/reference-types): no point stabilizing without #103516. - [Threads](https://github.com/webassembly/threads): requires rebuilding `std` #77839. - [Relaxed SIMD](https://github.com/WebAssembly/relaxed-simd): separate PR #117468. - [Multi Memory](https://github.com/WebAssembly/multi-memory): not implemented. See rust-lang/rust#117457 (comment) for more context. Documentation: rust-lang/reference#1420 Tracking issue: rust-lang/rust#44839
Stabilize Wasm target features that are in phase 4 and 5 This stabilizes the Wasm target features that are known to be working and in [phase 4 and 5](https://github.com/WebAssembly/proposals/tree/04fa8c810e1dc99ab399e41052a6e427ee988180). Feature stabilized: - [Non-trapping float-to-int conversions](https://github.com/WebAssembly/nontrapping-float-to-int-conversions) - [Import/Export of Mutable Globals](https://github.com/WebAssembly/mutable-global) - [Sign-extension operators](https://github.com/WebAssembly/sign-extension-ops) - [Bulk memory operations](https://github.com/WebAssembly/bulk-memory-operations) - [Extended Constant Expressions](https://github.com/WebAssembly/extended-const) Features not stabilized: - [Multi-value](https://github.com/WebAssembly/multi-value): requires rebuilding `std` #73755. - [Reference Types](https://github.com/WebAssembly/reference-types): no point stabilizing without #103516. - [Threads](https://github.com/webassembly/threads): requires rebuilding `std` #77839. - [Relaxed SIMD](https://github.com/WebAssembly/relaxed-simd): separate PR #117468. - [Multi Memory](https://github.com/WebAssembly/multi-memory): not implemented. See rust-lang/rust#117457 (comment) for more context. Documentation: rust-lang/reference#1420 Tracking issue: rust-lang/rust#44839
This stabilizes the Wasm target features that are known to be working and in phase 4 and 5.
Feature stabilized:
Features not stabilized:
std
Multi value Wasm compilation #73755.std
Tracking issue for WebAssembly atomics #77839.See #117457 (comment) for more context.
Documentation: rust-lang/reference#1420
Tracking issue: #44839