Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Summary

Promote aarch64-pc-windows-msvc to Tier 1 with Host Tools.

Motivation

About 30% of Rust users use Windows, while the majority of these developers and their customers are using x64 hardware, the usage of Arm64 Windows has been growing since it was first made available in Windows 10, and has been accelerating, especially with the availability of the SnapDragon X processors.

Guide-level explanation

No changes required: Rust tooling for Arm64 Windows has been available for a while now so this doesn’t affect the end user experience.

Reference-level explanation

Tier 1 targets must adhere to the Tier 1 Target Policy. Going through these requirements point-by-point:

Tier 1 targets must have substantial, widespread interest within the developer community, and must serve the ongoing needs of multiple production users of Rust across multiple organizations or projects. These requirements are subjective, and determined by consensus of the approving teams.

As mentioned above, Windows users comprise a substantial proportion of Rust developers, and Arm64 hardware is increasingly being used by them and their customers.

For the past two years, Arm64 PCs have accounted for 10-14% of Windows sales:

Overall, they are estimated to account for 1 to 1.5% of the Windows population:

While that’s a small relative number, in absolute terms it works out to 140 to 210 million devices.

For Rust itself, per the Rust download dashboard aarch64-pc-windows-msvc is the third most downloaded rustc non-tier 1 flavor (after x64 and Arm64 Linux musl flavors) and sees ~3% the number of downloads of x86_64-pc-windows-msvc.

The target maintainer team must include at least 3 developers.

aarch64-pc-windows-msvc is supported by the 5 *-pc-windows-msvc maintainers.

The target must build and pass tests reliably in CI, for all components that Rust’s CI considers mandatory. The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement.

The dist-aarch64-msvc CI job has been running reliably for over 4 years now, and I have new CI jobs working where Rust is built and tested on Arm64 Windows runners.

The following tests had to be disabled for aarch64-pc-windows-msvc:

The target must provide as much of the Rust standard library as is feasible and appropriate to provide.

The full Standard Library is available.

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

A try run of the new CI jobs completed in under 2 hours.

If running the testsuite requires additional infrastructure (such as physical systems running the target), the target maintainers must arrange to provide such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team. Such resources may be provided via cloud systems, via emulation, or via physical hardware.

The new CI jobs use the free windows-11-arm runners provided by GitHub.

Tier 1 targets must not have a hard requirement for signed, verified, or otherwise “approved” binaries. Developers must be able to build, run, and test binaries for the target on systems they control, or provide such binaries for others to run. (Doing so may require enabling some appropriate “developer mode” on such systems, but must not require the payment of any additional fee or other consideration, or agreement to any onerous legal agreements.)

There are no differences between x64 and Arm64 Windows in this regard.

All requirements for tier 2 apply.

Going through the Tier 2 policies:

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.

Understood.

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 al 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. The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

Understood, as part of the promotion PR I will add a page to Platform Support.

The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team.

There are no known deficiencies in LLVM’s support for Arm64 Windows.

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.

extern "C" correctly works for calling C code.

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.

aarch64-pc-windows-msvc can be cross-compiled from x86 and x64 Windows, or other platforms that can run those tools.

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.

There are no such license requirements for Arm64 Windows code.

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.

Understood.

The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

Understood, and this will be automated once promoted to Tier 1.

Drawbacks

The windows-11-arm runners provided by GitHub are relatively new, and so we do not know what the availability or reliability of these runners will be.

Rationale and alternatives

aarch64-pc-windows-msvc could be left as a Tier 2 with Host Tools target, but given the importance of this target to Microsoft and the increasing usage of Arm64 by Windows users, it will become more and more likely that issues with this target will need to be treated as critical. Catching issues early in development will prevent the need to Beta and Stable backports.

Prior art

Unresolved questions

None.

Future possibilities

  • Adding Arm64 Windows jobs to more Rust repos, such as cargo.
  • Promoting arm64ec-pc-windows-msvc to Tier 1.
  • Add a aarch64-pc-windows-gnu target.
  • Promote aarch64-pc-windows-gnullvm to Tier 1.