rfcs
rfcs copied to clipboard
rust-lang
RFC: Promote aarch64-pc-windows-msvc to Tier 1
related: promoting *-gnullvm to tier 2 with host tools https://github.com/rust-lang/compiler-team/issues/877
I've read through everything and it seems reasonable to me. While I would say that the current usage of Arm64 Windows falls a bit below our standards for Tier 1, I think the trend is just as important as the current numbers, and there it's very clearly upwards. For Arm64 MacOS it took us way too long to make it Tier 1 (because of GitHub lacking runners), so I'm glad that here we can be more proactive. My only concern here is the mentioned drawback, that the runners, being new, could prove themselves being unstable. Therefore, my approval here is predicated on having reliable CI for this target, and I think that if this proves to not be the case, it should be temporarily demoted until problems are resolved.
Labels are adjusted to T-compiler and T-release as defined by the target tier policy. @rfcbot merge One other thing that's missing is infra approval for the new CI job, but we can do this during the FCP.
Team member @Noratrieb has proposed to merge this. The next step is review by the rest of the tagged team members:
- [ ] @BoxyUwU
- [x] @Dylan-DPC
- [x] @Mark-Simulacrum
- [x] @Noratrieb
- [x] @SparrowLii
- [x] @cjgillot
- [x] @compiler-errors
- [x] @cuviper
- [x] @davidtwco
- [x] @estebank
- [x] @jieyouxu
- [x] @matthewjasper
- [x] @nagisa
- [x] @oli-obk
- [x] @petrochenkov
- [x] @pietroalbini
- [x] @spastorino
- [x] @wesleywiser
Concerns:
- ~~aarch64-windows-runners-are-in-public-preview~~ resolved by https://github.com/rust-lang/rfcs/pull/3817#issuecomment-3166086945
- ~~ci-reliability-testing~~ resolved by https://github.com/rust-lang/rfcs/pull/3817#issuecomment-3165597103
- ~~infra-approval~~ resolved by https://github.com/rust-lang/rfcs/pull/3817#issuecomment-2976964263
- ~~resolve ci-reliability-testing~~ resolved by https://github.com/rust-lang/rfcs/pull/3817#issuecomment-3165599695
- ~~resolve infra-approval~~ resolved by https://github.com/rust-lang/rfcs/pull/3817#issuecomment-2976964263
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
@rfcbot concern infra-approval
@rust-lang/infra are you okay with adding a new CI job for Arm64 Windows Tests as added in https://github.com/rust-lang/rust/pull/140136?
@rust-lang/infra are you okay with adding a new CI job for Arm64 Windows Tests as added in rust-lang/rust#140136?
FYI, I've updated and published https://github.com/rust-lang/rust/pull/140136
We'll discuss the job at today's infra team meeting. My 2 cents (and this does not need to hold off or block the RFC) is that we should run the tests first for a few weeks or months to judge the stability, and only then officially promote the target to Tier 1, rather than promoting it outright and then potentially demoting it back.
So, as per our #t-infra > meeting 2025-06-16, we're fine with promoting the target, but we would first like to see how stable is the ARM Windows runner, especially since it is currently in (public) preview. So I would appreciate if we could start running the tests with that runner on our CI for some time, and only after we see that it works well, we can go and officially promote the target.
@rfcbot concern resolve infra-approval @rfcbot concern ci-reliability-testing
OK, in that case you should go ahead and continue with your PR to add the CI. If it works reliably for a few months, we can merge the RFC, officially announcing the promotion and documenting it in the rustc book.
@rfcbot resolve infra-approval @rfcbot resolve resolve infra-approval
oops
Following up: https://github.com/rust-lang/rust/pull/140136 was merged over a week ago, and I haven't heard of any issues with the runners yet.
Hm, seems like the winapi crate doesn't work on windows-arm, see here. This means rustup-toolchain-install-master doesn't build on that host, making (at least) Miri development and native CI impossible.
Hm, seems like the winapi crate doesn't work on windows-arm, see here. This means rustup-toolchain-install-master doesn't build on that host, making (at least) Miri development and native CI impossible.
winapi 0.3.7 added support for Arm64 Windows: https://github.com/retep998/winapi-rs/commit/3792048cb07f9b762f8f0913293027759ea78db2
The current HEAD of rustup-toolchain-install-master (version 1.8.1) has updated to winapi 0.3.9, but it doesn't look like it's been published yet. I can't figure out which commit is associated with 1.8.0, but from the build log it looks like it's pulling in winapi 0.2.8.
At this point it should probably just switch to windows-sys. The winapi crate hasn't been updated for 5 years now.
At this point it should probably just switch to
windows-sys. Thewinapicrate hasn't been updated for 5 years now.
"just switch" is easier said then done when you're talking about a no-longer-actively-maintained dependency pulling in winapi, and that dependency doesn't have a clear replacement either.
The current HEAD of rustup-toolchain-install-master (version 1.8.1) has updated to winapi 0.3.9, but it doesn't look like it's been published yet. I can't figure out which commit is associated with 1.8.0, but from the build log it looks like it's pulling in winapi 0.2.8.
I removed the dependency on ansi_term in https://github.com/kennytm/rustup-toolchain-install-master/pull/61, which removed the winapi 0.2 dependency. Seems like that should be enough then. :)
pb is only 852 lines of Rust, I don't think it would be too hard to fork it and swap out winapi for windows-rs.
Ping... Rust, miri and stdarch have been successfully building on the Arm64 Windows runners for a while now.
@Noratrieb marked the reliability concern here. They mentioned a few months, so far it has been more like few weeks, but I haven't seen issues with that runner. GitHub support is still quite bad, they still haven't managed to add rustup/cargo to the image despite claiming that they already did so a ~week ago.
I asked t-infra at #t-infra > GitHub Arm64 runners private preview @ 💬 if there are any remaining concerns.
We discussed this at today's t-infra meeting, and we'd ideally like to wait with moving this target to Tier 1 until the ARM Windows GitHub Actions runners move out of preview/beta. While we also have aarch64-unknown-linux-gnu as Tier 1, which is technically also still in public preview/beta, we have already experience with running self-hosted Linux ARM64 runners, so if GitHub decided to pull back, we have reasonable alternatives. This is not true for ARM64 Windows, as we have no idea how to self-host that (if it is even possible).
I'd personally say that if it takes a long time to move out of public preview, we could re-evaluate this at a later time. But the current public preview hasn't been out for so long yet.
@rfcbot concern aarch64-windows-runners-are-in-public-preview
See https://github.com/rust-lang/rfcs/pull/3817#issuecomment-3150961659
@rfcbot resolve aarch64-windows-runners-are-in-public-preview
Runners are now out of public preview: https://github.blog/changelog/2025-08-07-arm64-hosted-runners-for-public-repositories-are-now-generally-available/
@rfcbot resolve ci-reliability-testing looks like the reliability of it has been good enough, so let's go ahead
@pietroalbini note that the concern has not been resolved, I think @jieyouxu needs to do that?
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
Thanks for the RFC! I have created a tracking issue for the remainder of the implementation: https://github.com/rust-lang/rust/issues/145671