Windows is not supported and is not being worked towards.
Why it has not been done
Nobody on the team runs it, so there is no consumer to validate against. That matters more here than usual, because the parts that would break are the least testable parts of the plugin:
-sys crates and their vendored C, which is where most of the corpus bugs lived- MSVC linking, a different model from the
lld path used everywhere else
- no
CCTool equivalent for the MSVC toolchain
- path handling, though the tool is in reasonable shape here:
PathBuf::join throughout, workspace.rs normalises backslashes, generate.rs uses DLL_SUFFIX, and build_script.rs maps windows to pc-windows-msvc
The gap is the Starlark layer and the C story, and both need a Windows machine that cares whether they work.
What would change the decision
Someone running Windows who needs this. A non-gating CI job that attempts a build and records what breaks would turn "unsupported" into a known list at almost no cost, and is the cheapest first step if that day comes.
Windows is not supported and is not being worked towards.
Why it has not been done
Nobody on the team runs it, so there is no consumer to validate against. That matters more here than usual, because the parts that would break are the least testable parts of the plugin:
-syscrates and their vendored C, which is where most of the corpus bugs livedlldpath used everywhere elseCCToolequivalent for the MSVC toolchainPathBuf::jointhroughout,workspace.rsnormalises backslashes,generate.rsusesDLL_SUFFIX, andbuild_script.rsmapswindowstopc-windows-msvcThe gap is the Starlark layer and the C story, and both need a Windows machine that cares whether they work.
What would change the decision
Someone running Windows who needs this. A non-gating CI job that attempts a build and records what breaks would turn "unsupported" into a known list at almost no cost, and is the cheapest first step if that day comes.