Add aarch64-pc-windows-msvc target (blocked: ring fails to cross-compile under cargo-xwin) #20

aarch64-pc-windows-msvc is not in [workspace.metadata.dist].targets, so there is no Windows-on-ARM binary. Adding the triple alone does not work — the cross-compile fails in ring. This issue records the reproduction so the next attempt does not rediscover it.

Windows on ARM is worth supporting: Snapdragon X laptops, and Windows dev VMs on Apple Silicon. Today those developers fall back to x64 emulation, and install.ps1 refuses outright.

The blocker

dist plan schedules the leg correctly — messense/cargo-xwin on ubuntu-22.04, pip3 install cargo-xwin, dist build --artifacts=local --target=aarch64-pc-windows-msvc. Running exactly that, in exactly that container:

error occurred in cc-rs: ... "clang" ... "--target=aarch64-pc-windows-msvc" ...
  "/imsvc" "/root/.cache/cargo-xwin/xwin/crt/include" ...
  "-c" ".../ring-0.17.14/pregenerated/sha256-armv8-win64.S"
clang: error: no such file or directory: '/imsvc'
warning: build failed

ring 0.17.14 assembles its ARM64 Windows .S files with plain clang (the GNU driver), which reads cargo-xwin's MSVC-style /imsvc include flags as filenames rather than flags. Reproduced twice, via cargo xwin build and via dist build.

zstd-sys is a second C dependency behind it that was never reached, so fixing ring may not be the end of it. zip and flate2 also carry C/asm.

Caveat on the repro: it ran under QEMU x86_64 emulation on an arm64 macOS host. That should not affect compiler flag parsing, but a GitHub-hosted ubuntu-22.04 run is the only 100% proof.

Why this cannot be discovered by merging and seeing

Nothing in this repo compiles this target before a tag push:

• ci.yml runs on ubuntu-latest with no target matrix.
• pr-run-mode = "plan" means the PR run does plan, not build.

And the failure is not contained. The host job needs every build-local-artifacts leg, so one failed leg means no GitHub Release, no S3 mirror, and — because npm-publish.yml is gated on workflow_run.conclusion == 'success' — no npm publish either. Adding the triple speculatively converts a working release pipeline into a broken one.

Anyone attempting this should prove the leg on a throwaway tag first, or add a build-only CI check for the target.

Two more places that need the triple

Adding it to targets is necessary but not sufficient. Both of these would otherwise ship a binary that does not work properly:

1. src/cli/update.rs:230-235 has no ("windows", "aarch64") arm, and the doc comment at :227 says as much: "None for hosts with no published build (Linux musl, Windows ARM64, …)". A shipped Windows ARM64 binary's own bugsee-cli update would refuse to run.
2. installer/install.ps1:24 throws unsupported Windows architecture ... (only x86_64/AMD64 is published).

Also stale once this lands: docs/upload-unification-activation.md:52-54,98-99, which enumerates the published target set.

Possible routes

1. Patch or pin ring so the ARM64 Windows assembly builds under clang-cl, or configure cc/cargo-xwin so the .S files get the MSVC driver.
2. Build that leg on a native windows-11-arm runner instead of cross-compiling, sidestepping cargo-xwin entirely. GitHub now offers Windows ARM64 runners.
3. Drop ring in favour of a backend that cross-compiles cleanly — much larger, and only worth it if other reasons pile up.

(2) looks like the shortest path, since it avoids the cross-compilation toolchain that is the actual problem.

Context

Split out of the @bugsee/cli per-platform npm packaging work, which originally carried this target and has been reduced to the five proven triples so it can ship. The npm platform-package table is keyed by Rust triple, so adding Windows ARM64 later is one row plus one triple plus the two fixes above.