libuv-sys-lite

Without pregenerated bindings, windows-aarch64 builds fall back to running bindgen at build time. GitHub's windows-11-arm64 runner image recently bumped LLVM 20 to 22, and bindgen 0.70 (clang-sys 1.8, which predates LLVM 22) silently generates unusable bindings against the new libclang — opaque size-1 structs and missing / — so the crate fails to compile. This is currently breaking denoland/deno CI, which uses this crate via ext/napi and builds natively on windows-11-arm runners (denoland/deno#36836; deno is carrying a vendored copy of this exact change in denoland/deno#36845 until a release with it exists). The bindings are copied from rather than generated on an arm64 machine: every field type libuv uses on Windows (HANDLE, SOCKET, ULONG_PTR, CRITICAL_SECTION, CONDITION_VARIABLE, ...) has an identical layout on both architectures, and the generated layout assertions verify that at compile time. Checked with . I deliberately didn't add a windows-aarch64 entry to the bindgen.yml workflow: generating on the current windows-11-arm runners would hit the same broken bindgen/libclang combination this PR works around. Could you cut a release with this when it lands? deno would then drop its vendored copy and pin the new version.

Fixes #1

I tried building Deno, which depends on this library https://github.com/denoland/deno/issues/27535 At which point I ran into From what I understand, this project depends on , which in turn depends on clang. Installing extra dependencies on Windows can be quite tricky. I also noticed that does not have a file, and instead has the generated bindings in the repository. Would it be reasonable for this project to do the same? If yes, I can try to provide a pull request. System: Windows 10