dylint: lint crates' ui fixtures cannot load their .so/.dll on windows runners (CARGO_BUILD_TARGET vs dylint's probe path)

[zackees]

Symptom

On a windows-latest runner, the Dylint workflow's "Test Dylint libraries" step — which runs each lint crate's own compiletest ui fixtures — fails:

diff of stderr:

-error: use fbuild_core::path::NormalizedPath::display_slash() instead of hand-rolled ... rewrite
-  --> $DIR/disallowed.rs:5:16
...
+error: could not load library
+  `D:/a/fbuild/fbuild/target/dylint-tests/debug/ban_manual_slash_normalize@nightly-2026-04-16.dll`:
+  LoadLibraryExW failed

The lint never loads, so the fixture compiles clean and compiletest reports the expected diagnostic as missing.

What is going on

Every lint crate's #[test] fn ui already documents half of this:

// Dylint 6.0.1 looks for its test library directly under
// <target>/debug, while Soldr selects the host through
// CARGO_BUILD_TARGET and Cargo writes to <target>/<host>/debug.
unsafe { std::env::remove_var("CARGO_BUILD_TARGET"); }

Clearing the variable is not sufficient on the runner: it happens inside the test process, after cargo has already decided where to place the artifact. The error path the harness then probes (<target>/dylint-tests/debug/...dll) is not where the .dll was written (<target>/dylint-tests/x86_64-pc-windows-msvc/debug/...).

Two details suggest looking closer before assuming it is only a path問題:

• LoadLibraryExW also fails when a dependent DLL cannot be resolved, not only when the file is absent — so a missing-file diagnosis should be confirmed rather than inferred from the message.
• The PATH the harness builds for the driver invocation begins with a stray ; and contains a lone C; fragment, i.e. it looks mangled somewhere in the assembly. That may be incidental to Git Bash path conversion, or may be the actual cause.

Why it is filed rather than fixed

#1359 added a windows-latest Dylint leg so Windows-gated source is actually linted. The lints themselves are clean there — the full workspace sweep passes. Only the lint crates' own self-tests fail, and those assert platform-independent behavior (each lint fires on its fixture) already covered by the ubuntu leg. So that step is scoped to ubuntu, and this is tracked here instead of blocking the gate.

Worth fixing if someone wants the ui fixtures exercised on Windows too — mostly as a guard against a lint whose diagnostic rendering differs per-OS, which is a real if narrow risk given several of these lints are about path spelling.

Likely fixes

1. Set CARGO_BUILD_TARGET= (empty) for the step itself rather than clearing it inside the test, so cargo places the artifact where the harness looks.
2. Or point the harness at the real location by setting DYLINT_LIBRARY_PATH to <target>/<host>/debug on Windows.
3. Confirm first whether the .dll exists at the probed path — that separates "wrong directory" from "dependent DLL missing", which need different fixes.