Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Move a wasm32-wasi-preview1-threads target to tier 2 #661

Closed
1 of 3 tasks
loganek opened this issue Aug 4, 2023 · 6 comments
Closed
1 of 3 tasks

Move a wasm32-wasi-preview1-threads target to tier 2 #661

loganek opened this issue Aug 4, 2023 · 6 comments
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@loganek
Copy link

loganek commented Aug 4, 2023

Proposal

The support for wasm32-wasi-preview1-threads target was added to a compiler as part of the PR: rust-lang/rust#112922. The target extends wasm32-wasi target (soon becoming a wasm32-wasi-preview1 target: rust-lang/stdarch#1417) by adding support for spawning threads based on the wasi-threads proposal. The wasm32-wasi-preview1-threads target uses the same source code as wasm32-wasi target for stdlib, but it enables additional flags (+atomics,+bulk-memory,+mutable-globals) and links against wasm32-wasi-threads libraries from WASI-SDK.

It was decided by the community that wasi-threads proposal will not proceed to the next stage as the threading support will be in the future added to Core WebAssembly standard (WIP proposal: https://github.com/abrown/thread-spawn). Given the early stage of the new, thread-spawn proposal, the wasi-threads proposal will be finalized even though it doesn't become part of WASI standard (so teams with a need for threading support can use it for the time being).

We propose moving the target to tier 2, given that:

The reason behind adding a new target as oppose to using existing wasm32-wasi / wasm32-wasi-preview1 was well explained in the original MCP: #574

There were also concerns raised by the community regarding adding this target in general, but they are addressed below:

  • wasi-threads is not part of the standard, and thus, experimental - as mentioned above, the proposal wasn't included in the standard, but there's an ongoing effort to finalize it and keep it as an extension of WASI snapshot preview1.
  • we might end-up with multiple WASM targets for supporting various set of features - Threads support is quite different to other extensions, as enabling it affects the implementation of the standard library. There are not many proposals that affect either the implementation of standard library or the ABI, so we don't think it is a concern.

We have reviewed the requirements for the tier 2 targets. The target meets all of the requirements except for documentation gaps which will be added if the MCP is accepted.

Our team at Amazon Prime Video will run tests regularly and fix build failures.

Mentors or Reviewers

@pnkfelix

Process

The main points of the Major Change Process are as follows:

  • File an issue describing the proposal.
  • A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
@loganek loganek added major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team labels Aug 4, 2023
@rustbot
Copy link
Collaborator

rustbot commented Aug 4, 2023

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Aug 4, 2023
@sunfishcode
Copy link
Member

In the blog post introducing wasi-threads support in wasmtime and wasi-sdk, @abrown wrote:

https://bytecodealliance.org/articles/wasi-threads

"Remember that wasi-threads, as a new WASI proposal, is still experimental — do not expect strong stability in the ABI, especially as WASI transitions to the component model."

From Wasmtime's perspective, the conditions which motivated @abrown to say this are still present. We said up front when wasi-threads was starting that the instance-per-thread model would not be workable for us, and that an approach such as thread-spawn would be workable. Wasi-threads has been useful in enabling experimentation, and supporting development of infrastructure for shared memories, but it's not something we guarantee will be supported for the long term in its current form.

@loganek
Copy link
Author

loganek commented Aug 4, 2023

@sunfishcode indeed the proposal is not a long-term solution. However, I don't think it doesn't mean we should not stabilize it and have it as an extension for (I guess) a number of usecases that need multi-threading support in their Wasm applications. Even though there's an active work on the thread-spawn proposal, it is still in an early stage. There will be runtimes (or instances of runtimes) that will support wasi-threads for a while, so from this perspective I think it makes sense to keep it around.

I've briefly discussed this with @abrown already and he seems to agree on finalizing wasi-threads, but I'm happy to discuss the concerns further if needed.

@abrown
Copy link

abrown commented Aug 4, 2023

My opinion on this should be pretty non-controversial here and probably doesn't sway things either direction: I'm committed to working on threads in WebAssembly, whatever form that may take, which is why I've contributed both to wasi-threads and thread-spawn. I'm going to be fine with whatever the community decides for either of those proposals; I completely understand the "instance-per-thread" problems @sunfishcode mentions and I am also sympathetic to the "meanwhile let's experiment with wasi-threads" argument @loganek is making. We probably need to hash out a clear plan in the WASI subgroup (or somewhere?) and there's more opinions than mine here.

But I do think we should head over to the Zulip stream to discuss this further before some Rust maintainer kicks us out of here 😁

@wesleywiser
Copy link
Member

@rustbot second

As mentioned, #574 already approved the idea of making this target Tier 2. Marking the target as Tier 2 does not commit us to shipping the target for any specific amount of time and the preview description in the name should help make users aware that this target is more in flux than many of our other targets. Thus, in the future, if we need to make significant changes to the target or drop it entirely, that is fine (but we should try to avoid unnecessary breakage 🙂). I don't see any reason not to continue forward with making this a Tier 2 target at this time.

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Aug 7, 2023
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Aug 10, 2023
@wesleywiser
Copy link
Member

@rustbot label -final-comment-period +major-change-accepted

@rustbot rustbot added major-change-accepted A major change proposal that was accepted to-announce Announce this issue on triage meeting and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Aug 25, 2023
@cuviper cuviper mentioned this issue Aug 27, 2023
Closed
@g0djan g0djan mentioned this issue Aug 29, 2023
Merged
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Sep 1, 2023
fmease added a commit to fmease/rust that referenced this issue Sep 6, 2023
@fmease
Rollup merge of rust-lang#115345 - g0djan:godjan/tier2-wasi-threads, …
dcf4c0b 
…r=WaffleLapkin

MCP661: Move wasm32-wasi-preview1-threads target to Tier 2

rust-lang/compiler-team#661

>A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

The feature is already implemented in [wasi-sdk(](https://github.com/WebAssembly/wasi-sdk) (C toolchain for WASM), and four different WASM runtimes([Wasmtime](https://github.com/bytecodealliance/wasmtime), [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime), [Wasmer](https://github.com/wasmerio/wasmer), [toywasm](https://github.com/yamt/toywasm)) are compatible with it.

>A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
>The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.

We already have a team of 4 developers. See [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). The documentation is being updated in this PR as the first occurrence.

>The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

It doesn't as it’s built on top of existing wasm32-wasi tier-2 target and it only extends stdlib by implementing
std:: thread::spawn/join.

> The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.

For build and running tests see *Building Rust programs* and *Testing* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Only manual test running is supported at the moment with some tweaks in the test runner codebase.

> The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

See *Platform requirements* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md)

> If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
>Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
>For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).

Justified in rust-lang/compiler-team#574 and I acknowledge these requirements and intend to ensure they are met.

> Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
>The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.
>As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

It does not, as it’s built as an extension of the existing tier 2 target (wasm32-wasi).

> The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.
>For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.
>If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.

Doesn't apply, the target re-uses existing backend and doesn't extend it

> If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.

Target does not support C code
>The target must build reliably in CI, for all components that Rust's CI considers mandatory.

The target reliably builds in CI already https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L143.

>The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.

The existing tier-2 target and this target as its extension [pass](rust-lang#112922 (comment)) for 14.5k+ tests/ui when tests are run manually(described in *Testing* in in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Can be tested in the CI as soon as the original target does.

> Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.

It doesn’t as it only slightly extends standard library of the existing target

> Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.

N/a given as it only extends stdlib of the existing target.

> In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.
>As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under "copyleft" terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust's existing practices of providing full corresponding source code. Note that anything added to the Rust repository itself must still use Rust's standard license terms.

Requirement are met, no legal issues.

> Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on tests failing for the target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 target, unless they have opted into such messages.
>Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I acknowledge these requirements and intend to ensure they are met.
> The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

The tests are run manually every week by `@g0djan` now.
While target has been in Tier 3, 2 issues(rust-lang#114608 and rust-lang#114610) have been raised. Both issues were addressed the same day and fixes has been merged by now.

> All requirements for tier 3 apply.

Target was initially accepted as a Tier 3 target in rust-lang#112922 .
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Sep 7, 2023
@GuillaumeGomez
Rollup merge of rust-lang#115345 - g0djan:godjan/tier2-wasi-threads, …
c752af4 
…r=WaffleLapkin

MCP661: Move wasm32-wasi-preview1-threads target to Tier 2

rust-lang/compiler-team#661

>A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

The feature is already implemented in [wasi-sdk(](https://github.com/WebAssembly/wasi-sdk) (C toolchain for WASM), and four different WASM runtimes([Wasmtime](https://github.com/bytecodealliance/wasmtime), [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime), [Wasmer](https://github.com/wasmerio/wasmer), [toywasm](https://github.com/yamt/toywasm)) are compatible with it.

>A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
>The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.

We already have a team of 4 developers. See [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). The documentation is being updated in this PR as the first occurrence.

>The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

It doesn't as it’s built on top of existing wasm32-wasi tier-2 target and it only extends stdlib by implementing
std:: thread::spawn/join.

> The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.

For build and running tests see *Building Rust programs* and *Testing* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Only manual test running is supported at the moment with some tweaks in the test runner codebase.

> The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

See *Platform requirements* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md)

> If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
>Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
>For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).

Justified in rust-lang/compiler-team#574 and I acknowledge these requirements and intend to ensure they are met.

> Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
>The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.
>As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

It does not, as it’s built as an extension of the existing tier 2 target (wasm32-wasi).

> The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.
>For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.
>If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.

Doesn't apply, the target re-uses existing backend and doesn't extend it

> If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.

Target does not support C code
>The target must build reliably in CI, for all components that Rust's CI considers mandatory.

The target reliably builds in CI already https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L143.

>The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.

The existing tier-2 target and this target as its extension [pass](rust-lang#112922 (comment)) for 14.5k+ tests/ui when tests are run manually(described in *Testing* in in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Can be tested in the CI as soon as the original target does.

> Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.

It doesn’t as it only slightly extends standard library of the existing target

> Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.

N/a given as it only extends stdlib of the existing target.

> In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.
>As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under "copyleft" terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust's existing practices of providing full corresponding source code. Note that anything added to the Rust repository itself must still use Rust's standard license terms.

Requirement are met, no legal issues.

> Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on tests failing for the target. Do not send automated messages or notifications (via any medium, including via ``@)`` to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 target, unless they have opted into such messages.
>Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I acknowledge these requirements and intend to ensure they are met.
> The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

The tests are run manually every week by ``@g0djan`` now.
While target has been in Tier 3, 2 issues(rust-lang#114608 and rust-lang#114610) have been raised. Both issues were addressed the same day and fixes has been merged by now.

> All requirements for tier 3 apply.

Target was initially accepted as a Tier 3 target in rust-lang#112922 .
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Sep 7, 2023
@GuillaumeGomez
Rollup merge of rust-lang#115345 - g0djan:godjan/tier2-wasi-threads, …
e4fd23a 
…r=WaffleLapkin

MCP661: Move wasm32-wasi-preview1-threads target to Tier 2

rust-lang/compiler-team#661

>A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

The feature is already implemented in [wasi-sdk(](https://github.com/WebAssembly/wasi-sdk) (C toolchain for WASM), and four different WASM runtimes([Wasmtime](https://github.com/bytecodealliance/wasmtime), [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime), [Wasmer](https://github.com/wasmerio/wasmer), [toywasm](https://github.com/yamt/toywasm)) are compatible with it.

>A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
>The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.

We already have a team of 4 developers. See [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). The documentation is being updated in this PR as the first occurrence.

>The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

It doesn't as it’s built on top of existing wasm32-wasi tier-2 target and it only extends stdlib by implementing
std:: thread::spawn/join.

> The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.

For build and running tests see *Building Rust programs* and *Testing* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Only manual test running is supported at the moment with some tweaks in the test runner codebase.

> The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

See *Platform requirements* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md)

> If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
>Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
>For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).

Justified in rust-lang/compiler-team#574 and I acknowledge these requirements and intend to ensure they are met.

> Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
>The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.
>As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

It does not, as it’s built as an extension of the existing tier 2 target (wasm32-wasi).

> The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.
>For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.
>If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.

Doesn't apply, the target re-uses existing backend and doesn't extend it

> If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.

Target does not support C code
>The target must build reliably in CI, for all components that Rust's CI considers mandatory.

The target reliably builds in CI already https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L143.

>The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.

The existing tier-2 target and this target as its extension [pass](rust-lang#112922 (comment)) for 14.5k+ tests/ui when tests are run manually(described in *Testing* in in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Can be tested in the CI as soon as the original target does.

> Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.

It doesn’t as it only slightly extends standard library of the existing target

> Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.

N/a given as it only extends stdlib of the existing target.

> In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.
>As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under "copyleft" terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust's existing practices of providing full corresponding source code. Note that anything added to the Rust repository itself must still use Rust's standard license terms.

Requirement are met, no legal issues.

> Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on tests failing for the target. Do not send automated messages or notifications (via any medium, including via ```@)``` to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 target, unless they have opted into such messages.
>Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I acknowledge these requirements and intend to ensure they are met.
> The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

The tests are run manually every week by ```@g0djan``` now.
While target has been in Tier 3, 2 issues(rust-lang#114608 and rust-lang#114610) have been raised. Both issues were addressed the same day and fixes has been merged by now.

> All requirements for tier 3 apply.

Target was initially accepted as a Tier 3 target in rust-lang#112922 .
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Sep 7, 2023
@GuillaumeGomez
Rollup merge of rust-lang#115345 - g0djan:godjan/tier2-wasi-threads, …
638e910 
…r=WaffleLapkin

MCP661: Move wasm32-wasi-preview1-threads target to Tier 2

rust-lang/compiler-team#661

>A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

The feature is already implemented in [wasi-sdk(](https://github.com/WebAssembly/wasi-sdk) (C toolchain for WASM), and four different WASM runtimes([Wasmtime](https://github.com/bytecodealliance/wasmtime), [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime), [Wasmer](https://github.com/wasmerio/wasmer), [toywasm](https://github.com/yamt/toywasm)) are compatible with it.

>A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
>The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.

We already have a team of 4 developers. See [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). The documentation is being updated in this PR as the first occurrence.

>The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

It doesn't as it’s built on top of existing wasm32-wasi tier-2 target and it only extends stdlib by implementing
std:: thread::spawn/join.

> The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.

For build and running tests see *Building Rust programs* and *Testing* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Only manual test running is supported at the moment with some tweaks in the test runner codebase.

> The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

See *Platform requirements* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md)

> If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
>Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
>For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).

Justified in rust-lang/compiler-team#574 and I acknowledge these requirements and intend to ensure they are met.

> Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
>The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.
>As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

It does not, as it’s built as an extension of the existing tier 2 target (wasm32-wasi).

> The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.
>For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.
>If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.

Doesn't apply, the target re-uses existing backend and doesn't extend it

> If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.

Target does not support C code
>The target must build reliably in CI, for all components that Rust's CI considers mandatory.

The target reliably builds in CI already https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L143.

>The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.

The existing tier-2 target and this target as its extension [pass](rust-lang#112922 (comment)) for 14.5k+ tests/ui when tests are run manually(described in *Testing* in in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Can be tested in the CI as soon as the original target does.

> Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.

It doesn’t as it only slightly extends standard library of the existing target

> Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.

N/a given as it only extends stdlib of the existing target.

> In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.
>As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under "copyleft" terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust's existing practices of providing full corresponding source code. Note that anything added to the Rust repository itself must still use Rust's standard license terms.

Requirement are met, no legal issues.

> Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on tests failing for the target. Do not send automated messages or notifications (via any medium, including via ````@)```` to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 target, unless they have opted into such messages.
>Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I acknowledge these requirements and intend to ensure they are met.
> The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

The tests are run manually every week by ````@g0djan```` now.
While target has been in Tier 3, 2 issues(rust-lang#114608 and rust-lang#114610) have been raised. Both issues were addressed the same day and fixes has been merged by now.

> All requirements for tier 3 apply.

Target was initially accepted as a Tier 3 target in rust-lang#112922 .
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 8, 2023
@matthiaskrgr
Rollup merge of rust-lang#115345 - g0djan:godjan/tier2-wasi-threads, …
6b00cfb 
…r=WaffleLapkin

MCP661: Move wasm32-wasi-preview1-threads target to Tier 2

rust-lang/compiler-team#661

>A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

The feature is already implemented in [wasi-sdk(](https://github.com/WebAssembly/wasi-sdk) (C toolchain for WASM), and four different WASM runtimes([Wasmtime](https://github.com/bytecodealliance/wasmtime), [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime), [Wasmer](https://github.com/wasmerio/wasmer), [toywasm](https://github.com/yamt/toywasm)) are compatible with it.

>A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
>The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.

We already have a team of 4 developers. See [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). The documentation is being updated in this PR as the first occurrence.

>The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

It doesn't as it’s built on top of existing wasm32-wasi tier-2 target and it only extends stdlib by implementing
std:: thread::spawn/join.

> The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.

For build and running tests see *Building Rust programs* and *Testing* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Only manual test running is supported at the moment with some tweaks in the test runner codebase.

> The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

See *Platform requirements* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md)

> If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
>Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
>For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).

Justified in rust-lang/compiler-team#574 and I acknowledge these requirements and intend to ensure they are met.

> Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
>The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.
>As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

It does not, as it’s built as an extension of the existing tier 2 target (wasm32-wasi).

> The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.
>For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.
>If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.

Doesn't apply, the target re-uses existing backend and doesn't extend it

> If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.

Target does not support C code
>The target must build reliably in CI, for all components that Rust's CI considers mandatory.

The target reliably builds in CI already https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L143.

>The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.

The existing tier-2 target and this target as its extension [pass](rust-lang#112922 (comment)) for 14.5k+ tests/ui when tests are run manually(described in *Testing* in in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Can be tested in the CI as soon as the original target does.

> Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.

It doesn’t as it only slightly extends standard library of the existing target

> Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.

N/a given as it only extends stdlib of the existing target.

> In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.
>As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under "copyleft" terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust's existing practices of providing full corresponding source code. Note that anything added to the Rust repository itself must still use Rust's standard license terms.

Requirement are met, no legal issues.

> Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on tests failing for the target. Do not send automated messages or notifications (via any medium, including via `````@)````` to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 target, unless they have opted into such messages.
>Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I acknowledge these requirements and intend to ensure they are met.
> The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

The tests are run manually every week by `````@g0djan````` now.
While target has been in Tier 3, 2 issues(rust-lang#114608 and rust-lang#114610) have been raised. Both issues were addressed the same day and fixes has been merged by now.

> All requirements for tier 3 apply.

Target was initially accepted as a Tier 3 target in rust-lang#112922 .
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Sep 8, 2023
@rust-timer
Unrolled build for rust-lang#115345
c036d53 
Rollup merge of rust-lang#115345 - g0djan:godjan/tier2-wasi-threads, r=WaffleLapkin

MCP661: Move wasm32-wasi-preview1-threads target to Tier 2

rust-lang/compiler-team#661

>A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

The feature is already implemented in [wasi-sdk(](https://github.com/WebAssembly/wasi-sdk) (C toolchain for WASM), and four different WASM runtimes([Wasmtime](https://github.com/bytecodealliance/wasmtime), [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime), [Wasmer](https://github.com/wasmerio/wasmer), [toywasm](https://github.com/yamt/toywasm)) are compatible with it.

>A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
>The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.

We already have a team of 4 developers. See [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). The documentation is being updated in this PR as the first occurrence.

>The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

It doesn't as it’s built on top of existing wasm32-wasi tier-2 target and it only extends stdlib by implementing
std:: thread::spawn/join.

> The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.

For build and running tests see *Building Rust programs* and *Testing* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Only manual test running is supported at the moment with some tweaks in the test runner codebase.

> The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

See *Platform requirements* in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md)

> If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
>Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
>For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).

Justified in rust-lang/compiler-team#574 and I acknowledge these requirements and intend to ensure they are met.

> Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
>The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.
>As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

It does not, as it’s built as an extension of the existing tier 2 target (wasm32-wasi).

> The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.
>For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.
>If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.

Doesn't apply, the target re-uses existing backend and doesn't extend it

> If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.

Target does not support C code
>The target must build reliably in CI, for all components that Rust's CI considers mandatory.

The target reliably builds in CI already https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L143.

>The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.

The existing tier-2 target and this target as its extension [pass](rust-lang#112922 (comment)) for 14.5k+ tests/ui when tests are run manually(described in *Testing* in in [src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/wasm32-wasi-preview1-threads.md). Can be tested in the CI as soon as the original target does.

> Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.

It doesn’t as it only slightly extends standard library of the existing target

> Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.

N/a given as it only extends stdlib of the existing target.

> In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.
>As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under "copyleft" terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust's existing practices of providing full corresponding source code. Note that anything added to the Rust repository itself must still use Rust's standard license terms.

Requirement are met, no legal issues.

> Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on tests failing for the target. Do not send automated messages or notifications (via any medium, including via `````@)````` to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 target, unless they have opted into such messages.
>Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I acknowledge these requirements and intend to ensure they are met.
> The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

The tests are run manually every week by `````@g0djan````` now.
While target has been in Tier 3, 2 issues(rust-lang#114608 and rust-lang#114610) have been raised. Both issues were addressed the same day and fixes has been merged by now.

> All requirements for tier 3 apply.

Target was initially accepted as a Tier 3 target in rust-lang#112922 .
@alexcrichton alexcrichton mentioned this issue Nov 27, 2023
Closed
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@abrown @wesleywiser @loganek @sunfishcode @apiraino @rustbot