fix aarch windows

Author: dmtrKovalenko

.github/workflows/rust.yml

@@ -8,6 +8,9 @@ on:
 
 env:
   CARGO_TERM_COLOR: always
+  # Ensure consistent macOS deployment target across all compiled objects
+  # (Rust, cc-compiled C code, and Zig-compiled zlob) to avoid linker warnings
+  MACOSX_DEPLOYMENT_TARGET: "13"
 
 jobs:
   test:
@@ -34,7 +37,7 @@ jobs:
           components: rustfmt, clippy
 
       - name: Run tests
-        run: cargo test --verbose
+        run: cargo test --verbose --workspace --exclude fff-nvim
 
   fmt:
     name: cargo fmt

crates/fff-c/src/ffi_types.rs

@@ -3,7 +3,7 @@
 //! These types use #[repr(C)] for C ABI compatibility and implement
 //! serde traits for JSON serialization.
 
-use std::ffi::{c_char, CString};
+use std::ffi::{CString, c_char};
 use std::ptr;
 
 use fff_core::git::format_git_status;

crates/fff-core/build.rs

@@ -2,10 +2,15 @@ fn main() {
     // On Windows MSVC, explicitly link the C runtime libraries.
     // This is needed because Zig-compiled static libraries (zlob) don't emit
     // /DEFAULTLIB directives for the MSVC CRT. Without this, symbols like
-    // strcmp, memcpy etc. from vendored C libraries (libgit2, lmdb) are
-    // unresolved when linking the cdylib.
+    // strcmp, memcpy, memchr etc. from vendored C libraries (libgit2, lmdb)
+    // are unresolved when linking the cdylib.
+    //
+    // We link both msvcrt (classic CRT) and ucrt (Universal CRT where memchr,
+    // strcmp etc. live on newer MSVC/ARM64 targets).
     let target = std::env::var("TARGET").unwrap_or_default();
     if target.contains("windows") && target.contains("msvc") {
         println!("cargo:rustc-link-lib=msvcrt");
+        println!("cargo:rustc-link-lib=ucrt");
+        println!("cargo:rustc-link-lib=vcruntime");
     }
 }