Promote the wasm32-wasip2 target to Tier 2 by alexcrichton · Pull Request #126967 · 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

Conversation25 Commits4 Checks0 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 }})

@alexcrichton

This commit promotes the wasm32-wasip2 Rust target to tier 2 as proposed in rust-lang/compiler-team#760. There are two major changes in this PR:

  1. The dist-various-2 container, which already produces the other WASI targets, now has an extra target added for wasm32-wasip2.
  2. A new wasm-component-ld binary is added to all host toolchains when LLD is enabled. This is the linker used for the wasm32-wasip2 target.

This new linker is added for all host toolchains to ensure that all host toolchains can produce the wasm32-wasip2 target. This is similar to how rust-lld was originally included for all host toolchains to be able to produce WebAssembly output when the targets were first added. The new linker is developed here and is pulled in via a crates.io-based dependency to the tree here.

@rustbot

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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 A-testsuite

Area: The testsuite used to check the correctness of rustc

S-waiting-on-review

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

T-bootstrap

Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

T-infra

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

labels

Jun 25, 2024

@alexcrichton

I'll note that rust-lang/compiler-team#760 is not complete so this shouldn't merge yet. I'm opening this up ahead of time to get feedback on the more technical side of things as opposed to the MCP-side of things.

One specific question I'd have is that this PR is adding more exceptions to the license check for crates that have an Apache-2.0 WITH LLVM-exception license. I understand it's easiest to stick to MIT OR Apache-2.0 like most other Rust crates and such, and to that effect we're going to try to relicense the wasm-tools repository to Apache-2.0 WITH LLVM-exception OR MIT OR Apache-2.0 soon. In lieu of this though, as that will probably take a bit, two questions:

Also I realize that licensing decisions are probably best not made in PRs, so this can also be considered as mostly highlighting the issue and if you know a better forum/location to discuss this I'm happy to raise something there.

@rust-log-analyzer

This comment has been minimized.

@Mark-Simulacrum

One specific question I'd have is that this PR is adding more exceptions to the license check for crates that have an Apache-2.0 WITH LLVM-exception license

My sense is that we're fine with extra dependencies with that license, especially in the same pool (i.e., wasm-related crates). cc @wesleywiser @davidtwco -- does that align with your expectations? Can you help drive the licensing story with the Foundation's help if needed?

I'm not sure whether re-licensing is worth the trouble or not as such. Though long-term it does likely hurt our ability to move code across the boundary of these crates, so if there's expectations that might be warranted it might be worth investing while there's less people involved (and so it's easier).

This is similar to how rust-lld was originally included for all host toolchains to be able to produce WebAssembly output when the targets were first added. The new linker is developed here and is pulled in via a crates.io-based dependency to the tree here.

Can you say how big the extra binary is? I don't remember the rationale back then, but it feels plausible that the linker should be part of the wasm target component... maybe I'm missing something obvious? (lld is distinct in that lots of targets use it -- at least now -- whereas this one seems like that may not be true for).

@bors

@alexcrichton

Ok sounds good on the licensing front. I opened bytecodealliance/wasm-tools#1637 and bytecodealliance/wit-bindgen#987 earlier anyway to start the process and see generally if it can be done, so that's progressing in parallel too.

As for binary sizes the linker locally is ~5M (4.6 on macos and 5.2 on linux). Making this part of the wasm component would require having a binary for each supported host architeture in the component as well which I think would be pretty difficult build-wise and also would make the wasm component significantly larger. IIRC we wrestled with this at the time when adding rust-lld as well and the decision was to ship it with all host components as that was the simplest solution at the time. Now that was also guided by the fact that we wanted to eventually use LLD for more targets one day (as has since happened) and this won't ever be used for any other target. I can look into size-optimizing the binary if 5M is too large.

@wesleywiser

My sense is that we're fine with extra dependencies with that license, especially in the same pool (i.e., wasm-related crates). cc @wesleywiser @davidtwco -- does that align with your expectations? Can you help drive the licensing story with the Foundation's help if needed?

Yes, I think that's ok. Obviously, it would be more ideal if we had the standard licensing applied so relicensing would still be preferable but not a blocker. Thanks @alexcrichton for starting that conversation in the bytecodealliance projects!

@alexcrichton

This commit promotes the wasm32-wasip2 Rust target to tier 2 as proposed in rust-lang/compiler-team#760. There are two major changes in this PR:

  1. The dist-various-2 container, which already produces the other WASI targets, now has an extra target added for wasm32-wasip2.
  2. A new wasm-component-ld binary is added to all host toolchains when LLD is enabled. This is the linker used for the wasm32-wasip2 target.

This new linker is added for all host toolchains to ensure that all host toolchains can produce the wasm32-wasip2 target. This is similar to how rust-lld was originally included for all host toolchains to be able to produce WebAssembly output when the targets were first added. The new linker is developed here and is pulled in via a crates.io-based dependency to the tree here.

@alexcrichton

Reuse preexisting macro and switch it to a "bootstrap tool" to try to resolve build issues.

@rust-log-analyzer

This comment has been minimized.

@alexcrichton

@rustbot

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

@alexcrichton

Ok I've redone a bit how the build is done to fix the build error from before, notably unconditionally using the stage0 compiler for the wasm-component-ld linker to ensure that it avoids the nightly issue with the ahash dependency. The FCP has finished here and otherwise the relicensing efforts are underway and should hopefully be complete in a month or so with new published versions at which point I'll update this to remove the exceptions.

In the meantime this should otherwise be ready for review and I'm happy to dig further into the binary size if that's a concern. The easiest win is to probably compile with -Cpanic=abort which I can try to figure out how to plumb through if desired.

@Mark-Simulacrum

@bors

📌 Commit 4cd6eee has been approved by Mark-Simulacrum

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

Jul 13, 2024

@Mark-Simulacrum

Let's land this. I think we can update the licensing and consider further improvements in binary size in the future, no need to block on that.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Jul 13, 2024

@workingjubilee

… r=Mark-Simulacrum

Promote the wasm32-wasip2 target to Tier 2

This commit promotes the wasm32-wasip2 Rust target to tier 2 as proposed in rust-lang/compiler-team#760. There are two major changes in this PR:

  1. The dist-various-2 container, which already produces the other WASI targets, now has an extra target added for wasm32-wasip2.
  2. A new wasm-component-ld binary is added to all host toolchains when LLD is enabled. This is the linker used for the wasm32-wasip2 target.

This new linker is added for all host toolchains to ensure that all host toolchains can produce the wasm32-wasip2 target. This is similar to how rust-lld was originally included for all host toolchains to be able to produce WebAssembly output when the targets were first added. The new linker is developed here and is pulled in via a crates.io-based dependency to the tree here.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Jul 13, 2024

@workingjubilee

… r=Mark-Simulacrum

Promote the wasm32-wasip2 target to Tier 2

This commit promotes the wasm32-wasip2 Rust target to tier 2 as proposed in rust-lang/compiler-team#760. There are two major changes in this PR:

  1. The dist-various-2 container, which already produces the other WASI targets, now has an extra target added for wasm32-wasip2.
  2. A new wasm-component-ld binary is added to all host toolchains when LLD is enabled. This is the linker used for the wasm32-wasip2 target.

This new linker is added for all host toolchains to ensure that all host toolchains can produce the wasm32-wasip2 target. This is similar to how rust-lld was originally included for all host toolchains to be able to produce WebAssembly output when the targets were first added. The new linker is developed here and is pulled in via a crates.io-based dependency to the tree here.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Jul 20, 2024

@matthiaskrgr

…dist-manifest, r=Mark-Simulacrum

Add wasm32-wasip2 to build-manifest tool

This is an accidental omission of mine from rust-lang#126967 which means that rustup target add wasm32-wasip2 isn't working on today's nightlies.

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

Jul 21, 2024

@rust-timer

Rollup merge of rust-lang#127867 - alexcrichton:add-wasm32-wasip2-to-dist-manifest, r=Mark-Simulacrum

Add wasm32-wasip2 to build-manifest tool

This is an accidental omission of mine from rust-lang#126967 which means that rustup target add wasm32-wasip2 isn't working on today's nightlies.

alexcrichton added a commit to alexcrichton/rust that referenced this pull request

Jul 22, 2024

@alexcrichton

This is another accidental omission from rust-lang#126967 (in addition to rust-lang#127867) which fixes an issue where wasm-component-ld isn't distributed via rustup just yet because while it's present in the sysroot it's not present in the tarballs.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Jul 23, 2024

@matthiaskrgr

…t-ld-for-real-this-time-maybe-let-see-after-this-merges, r=onur-ozkan

Fix inclusion of wasm-component-ld in dist artifacts

This is another accidental omission from rust-lang#126967 (in addition to rust-lang#127867) which fixes an issue where wasm-component-ld isn't distributed via rustup just yet because while it's present in the sysroot it's not present in the tarballs.

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

Jul 23, 2024

@rust-timer

Rollup merge of rust-lang#128060 - alexcrichton:include-wasm-component-ld-for-real-this-time-maybe-let-see-after-this-merges, r=onur-ozkan

Fix inclusion of wasm-component-ld in dist artifacts

This is another accidental omission from rust-lang#126967 (in addition to rust-lang#127867) which fixes an issue where wasm-component-ld isn't distributed via rustup just yet because while it's present in the sysroot it's not present in the tarballs.

alexcrichton added a commit to alexcrichton/rust that referenced this pull request

Sep 5, 2024

@alexcrichton

It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for wasm32-wasip2 required two PRs:

This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.

alexcrichton added a commit to alexcrichton/rust that referenced this pull request

Sep 5, 2024

@alexcrichton

It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for wasm32-wasip2 required two PRs:

This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.

This was referenced

Sep 5, 2024

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Sep 6, 2024

@workingjubilee

…release-notes, r=pietroalbini

Remove wasm32-wasip2's tier 2 status from release notes

It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for wasm32-wasip2 required two PRs:

This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Sep 6, 2024

@workingjubilee

…release-notes, r=pietroalbini

Remove wasm32-wasip2's tier 2 status from release notes

It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for wasm32-wasip2 required two PRs:

This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Sep 6, 2024

@matthiaskrgr

…release-notes, r=pietroalbini

Remove wasm32-wasip2's tier 2 status from release notes

It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for wasm32-wasip2 required two PRs:

This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.

RalfJung

# `wasm-component-ld`
This wrapper is a wrapper around the [`wasm-component-ld`] crates.io crate. That
crate. That crate is itself a thin wrapper around two pieces:

Choose a reason for hiding this comment

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

There's an incomplete sentence here (and still seems to be there on master).

Choose a reason for hiding this comment

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

Oh oops, I'll work on fixing this.

EDIT: #130034

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

Sep 6, 2024

@rust-timer

Rollup merge of rust-lang#129995 - alexcrichton:remove-wasm32-wasip2-release-notes, r=pietroalbini

Remove wasm32-wasip2's tier 2 status from release notes

It turns out the stars did not actually align for this to get released in Rust 1.81 alas. Full tier 2 status for wasm32-wasip2 required two PRs:

This wasn't caught until just after today's release so the plan is to remove the release notes for 1.81 and coordinate to instead add these as release notes to 1.82.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Sep 9, 2024

@workingjubilee

…nt-ld-comments, r=onur-ozkan

Fix enabling wasm-component-ld to match other tools

It was [pointed out recently][comment] that enabling wasm-component-ld as a host tool is different from other host tools. This commit refactors the logic to match by deduplicating selection of when to build other tools and then using the same logic for wasm-component-ld.

While here I also fixed a typo pointed out in rust-lang#126967 (review)

[comment]: rust-lang#127866 (comment)

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Sep 9, 2024

@workingjubilee

…nt-ld-comments, r=onur-ozkan

Fix enabling wasm-component-ld to match other tools

It was [pointed out recently][comment] that enabling wasm-component-ld as a host tool is different from other host tools. This commit refactors the logic to match by deduplicating selection of when to build other tools and then using the same logic for wasm-component-ld.

While here I also fixed a typo pointed out in rust-lang#126967 (review)

[comment]: rust-lang#127866 (comment)

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Sep 9, 2024

@workingjubilee

…nt-ld-comments, r=onur-ozkan

Fix enabling wasm-component-ld to match other tools

It was [pointed out recently][comment] that enabling wasm-component-ld as a host tool is different from other host tools. This commit refactors the logic to match by deduplicating selection of when to build other tools and then using the same logic for wasm-component-ld.

While here I also fixed a typo pointed out in rust-lang#126967 (review)

[comment]: rust-lang#127866 (comment)

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

Sep 9, 2024

@rust-timer

Rollup merge of rust-lang#130034 - alexcrichton:fix-some-wasm-component-ld-comments, r=onur-ozkan

Fix enabling wasm-component-ld to match other tools

It was [pointed out recently][comment] that enabling wasm-component-ld as a host tool is different from other host tools. This commit refactors the logic to match by deduplicating selection of when to build other tools and then using the same logic for wasm-component-ld.

While here I also fixed a typo pointed out in rust-lang#126967 (review)

[comment]: rust-lang#127866 (comment)

RalfJung pushed a commit to RalfJung/miri that referenced this pull request

Sep 10, 2024

@workingjubilee

…ments, r=onur-ozkan

Fix enabling wasm-component-ld to match other tools

It was [pointed out recently][comment] that enabling wasm-component-ld as a host tool is different from other host tools. This commit refactors the logic to match by deduplicating selection of when to build other tools and then using the same logic for wasm-component-ld.

While here I also fixed a typo pointed out in rust-lang/rust#126967 (review)

[comment]: rust-lang/rust#127866 (comment)

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

Sep 22, 2024

@he32

Pkgsrc changes:

Upstream changes:

Version 1.81.0 (2024-09-05)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

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

Oct 18, 2024

@tmeijn

This MR contains the following updates:

Package Update Change
rust minor 1.81.0 -> 1.82.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.82.0

Compare Source

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

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

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

Oct 27, 2024

@he32

Pkgsrc changes:

Upstream changes:

Version 1.82.0 (2024-10-17)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request

Nov 24, 2024

@he32

Pkgsrc changes:

Upstream changes:

Version 1.81.0 (2024-09-05)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request

Jan 24, 2025

@bors-ferrocene @pietroalbini

1245: [1.83] Backport KP docs, release notes fix r=pietroalbini a=Hoverbear

Backports

Also backports rust-lang/rust@24906b5 which which upstream is also doing: rust-lang/rust#135934

In the case of 24906b5, this is somewhat of a special circumstance. We noticed during our own release process that our 1.81 (so 24.11) release notes had changed and this change (along with rust-lang/rust#126967 which was removed with rust-lang/rust#129995) had disappeared. We confirmed the fix for rust-lang/rust#129960 is indeed in tree, but upstream never ported the release note update to their main branch. This port is being done in rust-lang/rust#135934.

Co-authored-by: Pietro Albini pietro.albini@ferrous-systems.com

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request

Feb 2, 2025

@he32

Pkgsrc changes:

Upstream changes:

Version 1.82.0 (2024-10-17)

Language

Compiler

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

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-bootstrap

Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

T-infra

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