Support building on Windows (MSVC) - #305
Open
TTC-NateC wants to merge 1 commit into
Open
Conversation
Two in-repo crates assumed a Unix host and broke the x86_64-pc-windows-msvc
build. Neither driver was buildable on Windows before this. Both fixes are
behavior-neutral on Unix.
antithesis-fuzzer: the libvoidstar shim passed the GCC/Clang-only flag
-Wextra to cl.exe (which rejects it) and included <dlfcn.h> to dlopen the
Linux-only libvoidstar coverage library. Use flag_if_supported("-Wextra") so
MSVC skips it, and compile no-op stubs under _WIN32. This matches the existing
runtime behavior on any non-Antithesis host, where libvoidstar is absent and
every coverage call already no-ops; the exported C ABI is unchanged.
cdp: the browser transport polled a raw socket file descriptor through
mio::unix::SourceFd, which does not exist on Windows (sockets have no fd, and
mio cannot register an arbitrary foreign socket there). cdp is a hard
dependency of the always-compiled browser driver, so this blocked the entire
build. Switch the transport to mio::net::TcpStream -- a first-class mio source
on every platform -- driving the tungstenite handshake non-blocking via
client_with_config, and enable mio's "net" feature. Only plain ws:// to a
local browser was ever supported (TLS was rejected), so nothing is lost. The
result is a single code path for all platforms rather than Windows-specific
branches.
Verified on Windows: the release CLI builds with both drivers, and
`bombadil browser test --headless` connects to Chrome and reports property
violations. The terminal driver builds but remains runtime-unstable on Windows
(pre-existing, unrelated to these changes).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two in-repo crates assumed a Unix host and broke the x86_64-pc-windows-msvc build. Neither driver was buildable on Windows before this. Both fixes are behavior-neutral on Unix.
antithesis-fuzzer: the libvoidstar shim passed the GCC/Clang-only flag -Wextra to cl.exe (which rejects it) and included <dlfcn.h> to dlopen the Linux-only libvoidstar coverage library. Use flag_if_supported("-Wextra") so MSVC skips it, and compile no-op stubs under _WIN32. This matches the existing runtime behavior on any non-Antithesis host, where libvoidstar is absent and every coverage call already no-ops; the exported C ABI is unchanged.
cdp: the browser transport polled a raw socket file descriptor through mio::unix::SourceFd, which does not exist on Windows (sockets have no fd, and mio cannot register an arbitrary foreign socket there). cdp is a hard dependency of the always-compiled browser driver, so this blocked the entire build. Switch the transport to mio::net::TcpStream -- a first-class mio source on every platform -- driving the tungstenite handshake non-blocking via client_with_config, and enable mio's "net" feature. Only plain ws:// to a local browser was ever supported (TLS was rejected), so nothing is lost. The result is a single code path for all platforms rather than Windows-specific branches.
Verified on Windows: the release CLI builds with both drivers, and
bombadil browser test --headlessconnects to Chrome and reports property violations. The terminal driver builds but remains runtime-unstable on Windows (pre-existing, unrelated to these changes).