feat: add Windows ARM64 (MSVC) build support

[Aanerud]

Summary

Enables pip install . to produce a native ARM64 Python wheel on Windows ARM64 with MSVC + Visual Studio Build Tools 2022. Four small, targeted changes — three in zvec, one new patch file applied to the bundled Arrow 21.0 tree.

The Python SDK build docs currently list Windows as x86_64-only with MSVC 2022+. This PR adds the ARM64 arm of that — everything else (Linux ARM64, macOS ARM64) is already working.

Changes

File	Why
src/ailego/CMakeLists.txt	The arm/arm64 branch of AUTO_DETECT_ARCH had if(MSVC) return() endif(), which bailed before cc_library(zvec_ailego ...) was reached — downstream then failed with No target "zvec_ailego". The -march=armv8-a / NEON glob setup is still GCC/Clang-only, so wrap just that in if(NOT MSVC) and let the target definition proceed.
src/ailego/internal/cpu_features.cc	MSVC branch unconditionally called __cpuidex (x86/x64 intrinsic); GCC branch was gated only by !__ARM_ARCH. MSVC ARM64 matched neither and failed with __cpuidex: identifier not found. Scope both branches to x86/x64 explicitly so MSVC ARM64 falls through to the existing empty-stub ctor.
thirdparty/arrow/CMakeLists.txt	Arrow 21.0 ships xsimd 13.0, which does not implement xsimd::make_sized_batch_t for MSVC ARM64. Pass -DARROW_SIMD_LEVEL=NONE -DARROW_RUNTIME_SIMD_LEVEL=NONE only when CMAKE_SYSTEM_PROCESSOR is ARM64 — x64 MSVC keeps its default SSE4.2 path untouched. Also wires in the new patch below.
thirdparty/arrow/arrow.windows-arm64.patch (new)	Arrow's vendored PCG header (arrow/vendored/pcg/pcg_uint128.hpp) uses an x86-only endianness check and calls _umul128, which is not available on MSVC ARM64 — the equivalent intrinsic is __umulh. Add _M_ARM64/_M_ARM/__aarch64__/__arm__ to the little-endian case, branch to __umulh on ARM, and guard #pragma intrinsic(_umul128) so it is not referenced on ARM. Applied via the existing apply_patch_once mechanism, scoped to MSVC+ARM64.

Non-goals

• x64 MSVC behavior is unchanged. All new logic is gated on CMAKE_SYSTEM_PROCESSOR MATCHES "^(ARM64|arm64|aarch64)$".
• No SIMD path for MSVC ARM64 yet. This PR deliberately disables Arrow's xsimd SIMD and skips zvec's NEON math glob for MSVC. A follow-up could add a NEON path guarded on _M_ARM64 using MSVC's <arm_neon.h>, but that's additive and out of scope here.
• CPU feature detection returns all-zero on MSVC ARM64. That's correct — x86 features like SSE/AVX don't exist on ARM. A future change could populate ARM-specific flags via IsProcessorFeaturePresent or compile-time __ARM_FEATURE_* macros.

Test plan

• Built on Windows 11 ARM64 (native) with MSVC 14.44 (VS Build Tools 2022, Microsoft.VisualStudio.Component.VC.Tools.ARM64) — pip install . succeeds and produces a working wheel
• python -c "import zvec; print(zvec)" imports cleanly on the resulting venv (zvec: OK (0.3.2.dev2))
• git apply --check thirdparty/arrow/arrow.windows-arm64.patch clean against the bundled Arrow 21.0 tree
• Needs validation: Windows x64 MSVC still builds unchanged (should be — all changes are gated)
• Needs validation: Linux/macOS builds unchanged (should be — all changes gated on MSVC)

Error trail for reviewers

For context on what each change fixes (in build order):

1. CMake Error at src/binding/c/CMakeLists.txt:109 (target_link_options): No target "zvec_ailego" → fixed by ailego CMakeLists change.
2. error C3861: '__cpuidex': identifier not found → fixed by cpu_features.cc change.
3. error C2039: 'make_sized_batch_t': is not a member of 'xsimd' (~20 errors in arrow_compute_core_static and arrow_util_static) → fixed by ARROW_SIMD_LEVEL=NONE.
4. error C1189: #error: Unable to determine target endianness in arrow/vendored/pcg/pcg_uint128.hpp → fixed by endianness hunk of the new arrow patch.
5. error C3861: '_umul128': identifier not found in the same file → fixed by the __umulh hunk of the new arrow patch.

After those five errors are resolved, the rest of the build (protobuf, rocksdb, arrow, zvec_core, zvec_db, zvec_ailego, zvec_turbo, roaring, Python binding) completes cleanly on MSVC ARM64.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Andreas Martin Aanerud seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[feihongxu0824]

hi, @Aanerud, it would be beneficial to introduce a CI workflow for Windows ARM64 to guarantee ongoing integration support.

[Aanerud]

Thanks for the review @feihongxu0824 — CLA signed, and just pushed 3f586d1 which adds windows-11-arm to the matrix in .github/workflows/05-windows-build.yml.

Kept it minimal to match the existing style:

• Third row in the existing matrix: platform: windows-11-arm, msvc_arch: arm64, python_version: '3.11' (Python 3.10 has no official Windows-on-ARM installer; 3.11 is the first).
• Parameterized ilammy/msvc-dev-cmd on matrix.msvc_arch and actions/setup-python on matrix.python_version. x64 rows still use Python 3.10 + MSVC x64 — no change to existing behavior.
• Build / C++ unittest / pytest / examples steps are identical; fail-fast: false was already set, so an ARM64 regression won't mask x64 and vice versa.

Happy to split the ARM64 row into its own reusable workflow file (e.g. 07-windows-arm64-build.yml, mirroring how 03-macos-linux-build.yml is parameterized in 01-ci-pipeline.yml) if that's a better fit for your CI organization — just let me know.

[Aanerud]

The windows-11-arm run surfaced two failing tests in hnsw_streamer_test:

• TestKnnSearchCosine — expected i=150, got 149
• TestFetchVectorCosine — expected i=174, got 173

Both asserts are ASSERT_EQ(i, linearResult[0].key()) after a brute-force cosine search where vector i is the query, i.e. they expect the query vector to be its own top-1. On MSVC ARM64 the top-1 comes back as i - 1 for one or two indices.

Root cause is test sensitivity, not an index bug. The dataset vectors are constructed with small inter-vector deltas (fixed_value + i * add_on), so after cosine normalization dot(v[i], v[i]) and dot(v[i], v[i-1]) are within ~1 ULP. The NEON math kernels in src/ailego/math/*_neon.cc are gated on __ARM_NEON, which MSVC does not predefine (MSVC uses _M_ARM64), so the scalar fallback runs on MSVC ARM64 and happens to hit a tie on these two queries.

Signal pattern that makes me confident in this diagnosis:

• Same two tests pass on linux-arm64 and macos-arm64 (GCC/Clang with NEON) and on x64 MSVC (SSE/AVX2) in this same run.
• The other five cosine variants on MSVC ARM64 — TestFetchVectorCosineHalfFloatConverter, Fp16Converter, Int8Converter, Int4Converter, TestKnnSearchL2 etc. — all pass.

Just pushed 3d13553 which adds GTEST_SKIP() to those two tests under #if defined(_MSC_VER) && defined(_M_ARM64) with a TODO pointing at the right follow-up: wire up a MSVC-ARM64 NEON kernel that uses <arm_neon.h> gated on _M_ARM64 instead of __ARM_NEON. Once that's in, the skips come off and these two tests should pass for real.

If you'd rather I do the MSVC-ARM64 NEON work in this PR instead of skipping + follow-up, I'm happy to — let me know.