Promote 64-bit windows-gnullvm Targets to Tier 2 with Host Tools

[mati865]

Proposal

Promote aarch64-pc-windows-gnullvm and x86_64-pc-windows-gnullvm from tier 2 target (without host tools) to tier 2 hosts. i686-pc-windows-gnullvm is not considered for various reasons, like not being able to host itself without intrusive LLVM patches (memory mapped IO and 32-bit Windows processes don't go well together).

The benefits over windows-gnu targets listed at #710 still apply.
Moreover, aarch64-pc-windows-gnullvm host toolchain would allow avoiding proprietary tools on AArch64 Windows.

(the part below is based on #870)

Requirements for Tier 2 with Host Tools

Depending on the target, its capabilities, its performance, and the likelihood of use for any given tool, the host tools provided for a tier 2 target may include only rustc and cargo, or may include additional tools such as clippy and rustfmt.

MSYS2 already provides host rustc, cargo, clippy and rustfmt for these targets. Initially there were some issues, but at this point there are far fewer known issues compared to windows-gnu.

Approval of host tools will take into account the additional time required to build the host tools, and the substantial additional storage required for the host tools.

Cross-compilation (without LLVM tools because of a bootstrap bug) completes within 2 hours: rust-lang/rust#140772 (comment)

The host tools must have direct value to people other than the target's maintainers. (It may still be a niche target, but the host tools must not be exclusively useful for an inherently closed group.) This requirement will be evaluated independently from the corresponding tier 2 requirement.
There must be a reasonable expectation that the host tools will be used, for purposes other than to prove that they can be used.

I don't have exact numbers, but I know at least some people using MSYS2 also use MSYS2 provided windows-gnullvm. Should be also useful to anyone wanting code coverage on Windows without having to install Windows SDK.

The host tools must build and run reliably in CI (for all components that Rust's CI considers mandatory), though they may or may not pass tests.

From what I can tell, they are more reliable than some of tier 1 host toolchains.

Building host tools for the target must not take substantially longer than building host tools for other targets, and should not substantially raise the maintenance burden of the CI infrastructure.

Even with profilers, sanitizers, etc. build time should be comparable with windows-gnu.

The host tools must provide a substantively similar experience as on other targets, subject to reasonable target limitations.

Windows-gnullvm host tools do not work at all without mingw-w64+LLVM toolchain in PATH. This is a difference compared to windows-gnu host toolchains which can build and link most of the pure Rust crates without C toolchain in PATH.
Otherwise it's mostly the same thing as with windows-gnu.

If the host tools for the platform would normally be expected to be signed or equivalent (e.g. if running unsigned binaries or similar involves a "developer mode" or an additional prompt), it must be possible for the Rust project's automated builds to apply the appropriate signature process, without any manual intervention by either Rust developers, target maintainers, or a third party. This process must meet the approval of the infrastructure team.

Signing is not required.

Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible.

These targets are already well-supported by cross compilation.

All requirements for tier 2 apply.

These targets are already supported in Tier 2.

[rustbot]

Important

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.

Concerns or objections can formally be registered here by adding a comment.

@rfcbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rfcbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[Noratrieb]

@rustbot second