Fixes #64

Summary

Force libmimalloc-sys/c_src/mimalloc/src/static.c to be compiled as C++ on every windows-msvc target, not just MSVC-style drivers. This fixes the aarch64-pc-windows-msvc build under TARGET_CC=clang and aligns the post-#16 cc-rs path with the pre-#16 cmake path, which explicitly set MI_USE_CXX=ON.

Why

Since libmimalloc-sys2 0.1.55 bumped the bundled mimalloc submodule, aarch64-pc-windows-msvc builds invoked with TARGET_CC=clang fail:

./c_src/mimalloc/include/mimalloc/atomic.h:230:14: error: call to undeclared function '__ldar64'
./c_src/mimalloc/include/mimalloc/atomic.h:252:7:  error: call to undeclared function '__stlr64'
./c_src/mimalloc/include/mimalloc/atomic.h:273:14: error: call to undeclared function '__ldar64'
./c_src/mimalloc/include/mimalloc/atomic.h:298:7:  error: call to undeclared function '__stlr64'
error: failed to run custom build command for `libmimalloc-sys2 v0.1.55`

Failing CI run (rolldown): https://github.com/rolldown/rolldown/actions/runs/25723489236/job/75533705378

Same regression reported in oxc: oxc-project/oxc#22329

Root cause

atomic.h has three mutually exclusive branches:

#if defined(__cplusplus)            // <atomic> path (always safe)
#elif defined(_MSC_VER)             // MSVC plain-C wrapper using MSVC intrinsics
#else                               // C11 <stdatomic.h> path

• clang invoked as clang --target=*-pc-windows-msvc defines _MSC_VER for MSVC ABI compatibility, so when the source is compiled as C it takes the _MSC_VER branch.
• The _M_ARM64 sub-branch of that path calls __ldar64 / __stlr64, which are MSVC-only intrinsics. clang does not declare them in C mode on Windows, hence the build failure.
• Upstream mimalloc explicitly recommends "always compile as C++ when using MSVC" and uses set_source_files_properties(... LANGUAGE CXX) in its own CMakeLists.txt to enforce this. Compiling as C++ takes the #if defined(__cplusplus) branch and avoids the MSVC-intrinsics path entirely.

Why the previous code did not already do this

build_mimalloc_win was introduced in #16, replacing a cmake path that explicitly set MI_USE_CXX=ON. The intent was preserved as:

.cpp(false)
...
if build.get_compiler().is_like_msvc() {
    build.cpp(true);
}

However cc::Build::cpp(true) does not inject /TP or -x c++ (a search of cc-1.2.x confirms this) — it only changes which env vars are read (CXX / CXXFLAGS), the compiler binary name resolution (clang → clang++, gcc → g++), and C++ stdlib linking. cl.exe still compiles static.c as C, and clang++ dispatches by extension and also compiles .c as C. So MI_USE_CXX=ON was never actually re-implemented after the cmake → cc-rs migration; the bug was masked by coincidence:

The recent mimalloc submodule bump made the _M_ARM64 sub-branch the only path that matters on ARM64, exposing the coincidence.

Fix

Explicitly force C++ compilation of static.c regardless of driver:

if build.get_compiler().is_like_msvc() {
    build.flag("/TP");
} else {
    build.flag("-xc++");
}

cpp(true) is still kept so CXX / C++ stdlib resolution behave correctly. /TP covers cl.exe and clang-cl.exe; -xc++ covers plain clang.exe (gnu-driver) with --target=*-pc-windows-msvc.

This restores the original MI_USE_CXX=ON semantics that #16 intended to carry over.

Related

Downstream pin workarounds (can be reverted once this lands and a new libmimalloc-sys2 is published):

• fix(ci): pin mimalloc-safe to 0.1.58 rolldown/rolldown#9361 — pin mimalloc-safe = "=0.1.58"
• chore(deps): pin libmimalloc-sys2 to 0.1.54 rolldown/rolldown#9372 — pin libmimalloc-sys2 = "=0.1.54" in Cargo.lock
• fix(ci): pin mimalloc-safe to 0.1.58 oxc-project/oxc#22329 — same regression