-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Promote the wasm32-wasip2
target to Tier 2
#126967
Conversation
rustbot has assigned @Mark-Simulacrum. Use |
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
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. |
This comment has been minimized.
This comment has been minimized.
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).
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). |
☔ The latest upstream changes (presumably #127133) made this pull request unmergeable. Please resolve the merge conflicts. |
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. |
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! |
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][wasm-component-ld] and is pulled in via a crates.io-based dependency to the tree here. [wasm-component-ld]: https://github.com/bytecodealliance/wasm-component-ld
Reuse preexisting macro and switch it to a "bootstrap tool" to try to resolve build issues.
824002b
to
1afdd45
Compare
This comment has been minimized.
This comment has been minimized.
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging. |
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 |
@bors r+ |
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. |
… 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][wasm-component-ld] and is pulled in via a crates.io-based dependency to the tree here. [wasm-component-ld]: https://github.com/bytecodealliance/wasm-component-ld
… 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][wasm-component-ld] and is pulled in via a crates.io-based dependency to the tree here. [wasm-component-ld]: https://github.com/bytecodealliance/wasm-component-ld
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.
This commit updates the support for the `wasm-component-ld` tool from rust-lang#126967 to conditionally build it rather than unconditionally building it when LLD is enabled. This support is disabled by default and can be enabled by one of two means: * the `extended` field in `config.toml` which dist builders use to build a complete set of tools for each host platform. * a `"wasm-component-ld"` entry in the `tools` section of `config.toml`. Neither of these are enabled by default meaning that most local builds will likely not have this new tool built. Dist builders should still, however, build the 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.
…t-ld-by-default, r=onur-ozkan Conditionally build `wasm-component-ld` This commit updates the support for the `wasm-component-ld` tool from rust-lang#126967 to conditionally build rather than unconditionally building it when LLD is enabled. This support is disabled by default and can be enabled by one of two means: * the `extended` field in `config.toml` which dist builders use to build a complete set of tools for each host platform. * a `"wasm-component-ld"` entry in the `tools` section of `config.toml`. Neither of these are enabled by default meaning that most local builds will likely not have this new tool built. Dist builders should still, however, build the tool.
…t-ld-by-default, r=onur-ozkan Conditionally build `wasm-component-ld` This commit updates the support for the `wasm-component-ld` tool from rust-lang#126967 to conditionally build rather than unconditionally building it when LLD is enabled. This support is disabled by default and can be enabled by one of two means: * the `extended` field in `config.toml` which dist builders use to build a complete set of tools for each host platform. * a `"wasm-component-ld"` entry in the `tools` section of `config.toml`. Neither of these are enabled by default meaning that most local builds will likely not have this new tool built. Dist builders should still, however, build the tool.
Rollup merge of rust-lang#127866 - alexcrichton:disable-wasm-component-ld-by-default, r=onur-ozkan Conditionally build `wasm-component-ld` This commit updates the support for the `wasm-component-ld` tool from rust-lang#126967 to conditionally build rather than unconditionally building it when LLD is enabled. This support is disabled by default and can be enabled by one of two means: * the `extended` field in `config.toml` which dist builders use to build a complete set of tools for each host platform. * a `"wasm-component-ld"` entry in the `tools` section of `config.toml`. Neither of these are enabled by default meaning that most local builds will likely not have this new tool built. Dist builders should still, however, build the tool.
…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.
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.
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.
…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.
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.
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: * rust-lang#126967 - this made it into Rust 1.81 * rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead 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.
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: * rust-lang#126967 - this made it into Rust 1.81 * rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead 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.
…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: * rust-lang#126967 - this made it into Rust 1.81 * rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead 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.
…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: * rust-lang#126967 - this made it into Rust 1.81 * rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead 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.
…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: * rust-lang#126967 - this made it into Rust 1.81 * rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead 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.
# `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: |
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.
There's an incomplete sentence here (and still seems to be there on master).
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.
Oh oops, I'll work on fixing this.
EDIT: #130034
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: * rust-lang#126967 - this made it into Rust 1.81 * rust-lang#127867 - this didn't make the cut and is in Rust 1.82 instead 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.
…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)
…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)
…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)
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)
…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)
Pkgsrc changes: * Adapt patches, apply to new vendored crates where needed. * Back-port rust pull request 130110, "make dist vendoring configurable" * Disable "dist vendoring", otherwise cargo would try to access the network during the build phase. Upstream changes: Version 1.81.0 (2024-09-05) ========================== Language -------- - [Abort on uncaught panics in `extern "C"` functions.] (rust-lang/rust#116088) - [Fix ambiguous cases of multiple `&` in elided self lifetimes.] (rust-lang/rust#117967) - [Stabilize `#[expect]` for lints (RFC 2383),] (rust-lang/rust#120924) like `#[allow]` with a warning if the lint is _not_ fulfilled. - [Change method resolution to constrain hidden types instead of rejecting method candidates.] (rust-lang/rust#123962) - [Bump `elided_lifetimes_in_associated_constant` to deny.] (rust-lang/rust#124211) - [`offset_from`: always allow pointers to point to the same address.] (rust-lang/rust#124921) - [Allow constraining opaque types during subtyping in the trait system.] (rust-lang/rust#125447) - [Allow constraining opaque types during various unsizing casts.] (rust-lang/rust#125610) - [Deny keyword lifetimes pre-expansion.] (rust-lang/rust#126762) Compiler -------- - [Make casts of pointers to trait objects stricter.] (rust-lang/rust#120248) - [Check alias args for well-formedness even if they have escaping bound vars.] (rust-lang/rust#123737) - [Deprecate no-op codegen option `-Cinline-threshold=...`.] (rust-lang/rust#124712) - [Re-implement a type-size based limit.] (rust-lang/rust#125507) - [Properly account for alignment in `transmute` size checks.] (rust-lang/rust#125740) - [Remove the `box_pointers` lint.] (rust-lang/rust#126018) - [Ensure the interpreter checks bool/char for validity when they are used in a cast.] (rust-lang/rust#126265) - [Improve coverage instrumentation for functions containing nested items.] (rust-lang/rust#127199) - Target changes: - [Add Tier 3 `no_std` Xtensa targets:] (rust-lang/rust#125141) `xtensa-esp32-none-elf`, `xtensa-esp32s2-none-elf`, `xtensa-esp32s3-none-elf` - [Add Tier 3 `std` Xtensa targets:] (rust-lang/rust#126380) `xtensa-esp32-espidf`, `xtensa-esp32s2-espidf`, `xtensa-esp32s3-espidf` - [Add Tier 3 i686 Redox OS target:] (rust-lang/rust#126192) `i686-unknown-redox` - [Promote `arm64ec-pc-windows-msvc` to Tier 2.] (rust-lang/rust#126039) - [Promote `wasm32-wasip2` to Tier 2.] (rust-lang/rust#126967) - [Promote `loongarch64-unknown-linux-musl` to Tier 2 with host tools.] (rust-lang/rust#126298) - [Enable full tools and profiler for LoongArch Linux targets.] (rust-lang/rust#127078) - [Unconditionally warn on usage of `wasm32-wasi`.] (rust-lang/rust#126662) (see compatibility note below) - Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Split core's `PanicInfo` and std's `PanicInfo`.] (rust-lang/rust#115974) (see compatibility note below) - [Generalize `{Rc,Arc}::make_mut()` to unsized types.] (rust-lang/rust#116113) - [Replace sort implementations with stable `driftsort` and unstable `ipnsort`.] (rust-lang/rust#124032) All `slice::sort*` and `slice::select_nth*` methods are expected to see significant performance improvements. See the [research project] (https://github.com/Voultapher/sort-research-rs) for more details. - [Document behavior of `create_dir_all` with respect to empty paths.] (rust-lang/rust#125112) - [Fix interleaved output in the default panic hook when multiple threads panic simultaneously.] (rust-lang/rust#127397) - Fix `Command`'s batch files argument escaping not working when file name has trailing whitespace or periods (CVE-2024-43402). Stabilized APIs --------------- - [`core::error`] (https://doc.rust-lang.org/stable/core/error/index.html) - [`hint::assert_unchecked`] (https://doc.rust-lang.org/stable/core/hint/fn.assert_unchecked.html) - [`fs::exists`] (https://doc.rust-lang.org/stable/std/fs/fn.exists.html) - [`AtomicBool::fetch_not`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicBool.html#method.fetch_not) - [`Duration::abs_diff`] (https://doc.rust-lang.org/stable/core/time/struct.Duration.html#method.abs_diff) - [`IoSlice::advance`] (https://doc.rust-lang.org/stable/std/io/struct.IoSlice.html#method.advance) - [`IoSlice::advance_slices`] (https://doc.rust-lang.org/stable/std/io/struct.IoSlice.html#method.advance_slices) - [`IoSliceMut::advance`] (https://doc.rust-lang.org/stable/std/io/struct.IoSliceMut.html#method.advance) - [`IoSliceMut::advance_slices`] (https://doc.rust-lang.org/stable/std/io/struct.IoSliceMut.html#method.advance_slices) - [`PanicHookInfo`] (https://doc.rust-lang.org/stable/std/panic/struct.PanicHookInfo.html) - [`PanicInfo::message`] (https://doc.rust-lang.org/stable/core/panic/struct.PanicInfo.html#method.message) - [`PanicMessage`] (https://doc.rust-lang.org/stable/core/panic/struct.PanicMessage.html) These APIs are now stable in const contexts: - [`char::from_u32_unchecked`] (https://doc.rust-lang.org/stable/core/char/fn.from_u32_unchecked.html) (function) - [`char::from_u32_unchecked`] (https://doc.rust-lang.org/stable/core/primitive.char.html#method.from_u32_unchecked) (method) - [`CStr::count_bytes`] (https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.count_bytes) - [`CStr::from_ptr`] (https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.from_ptr) Cargo ----- - [Generated `.cargo_vcs_info.json` is always included, even when `--allow-dirty` is passed.] (rust-lang/cargo#13960) - [Disallow `package.license-file` and `package.readme` pointing to non-existent files during packaging.] (rust-lang/cargo#13921) - [Disallow passing `--release`/`--debug` flag along with the `--profile` flag.] (rust-lang/cargo#13971) - [Remove `lib.plugin` key support in `Cargo.toml`. Rust plugin support has been deprecated for four years and was removed in 1.75.0.] (rust-lang/cargo#13902) Compatibility Notes ------------------- * Usage of the `wasm32-wasi` target will now issue a compiler warning and request users switch to the `wasm32-wasip1` target instead. Both targets are the same, `wasm32-wasi` is only being renamed, and this [change to the WASI target] (https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html) is being done to enable removing `wasm32-wasi` in January 2025. * We have renamed `std::panic::PanicInfo` to `std::panic::PanicHookInfo`. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0. `core::panic::PanicInfo` will remain unchanged, however, as this is now a *different type*. The reason is that these types have different roles: `std::panic::PanicHookInfo` is the argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in std context (where panics can have an arbitrary payload), while `core::panic::PanicInfo` is the argument to the [`#[panic_handler]`](https://doc.rust-lang.org/nomicon/panic-handler.html) in no_std context (where panics always carry a formatted *message*). Separating these types allows us to add more useful methods to these types, such as `std::panic::PanicHookInfo::payload_as_str()` and `core::panic::PanicInfo::message()`. * The new sort implementations may panic if a type's implementation of [`Ord`](https://doc.rust-lang.org/std/cmp/trait.Ord.html) (or the given comparison function) does not implement a [total order](https://en.wikipedia.org/wiki/Total_order) as the trait requires. `Ord`'s supertraits (`PartialOrd`, `Eq`, and `PartialEq`) must also be consistent. The previous implementations would not "notice" any problem, but the new implementations have a good chance of detecting inconsistencies, throwing a panic rather than returning knowingly unsorted data. * [In very rare cases, a change in the internal evaluation order of the trait solver may result in new fatal overflow errors.] (rust-lang/rust#126128) 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. - [Add a Rust-for Linux `auto` CI job to check kernel builds.] (rust-lang/rust#125209)
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:dist-various-2
container, which already produces the other WASI targets, now has an extra target added forwasm32-wasip2
.wasm-component-ld
binary is added to all host toolchains when LLD is enabled. This is the linker used for thewasm32-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 howrust-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.