[bazel] Pin Windows target platform to gnullvm to fix proc-macro E0463

Windows CI pinned only --host_platform=//:local_windows_gnullvm, leaving the
target platform as Bazel's auto-detected x64_windows. That platform lacks the
@llvm//constraints/windows/abi:gnullvm and crt:msvcrt constraints, so the
Rust toolchain resolved for the target config was a different variant than the
one resolved for the exec (host) config.

The visible symptom: compiling crates like `scroll` (target config
x64_windows-fastbuild) referenced their proc-macro DLLs in the exec config
(local_windows_gnullvm-opt-exec). Because the two configs resolved mismatched
toolchains, the gnullvm proc-macro DLL (scroll_derive, time_macros) could not
be loaded by the target rustc and failed with E0463: can't find crate.

Pinning --platforms to //:local_windows_gnullvm as well puts the whole build
on a single gnullvm toolchain, exactly as the RBE config already pins both
--host_platform and --platforms. The extra abi/crt constraints only add to the
host-inherited platform, so non-Rust toolchains (Java, .NET, Python) resolve
unchanged.

Also removes the unused local_windows_msvc platform: the hermetic LLVM Windows
linker is hardwired to gnu-mode clang++ (-target x86_64-w64-windows-gnu)
regardless of the abi constraint, so an msvc host can never link rustc's
MSVC-style output. gnullvm is the only viable host, making that platform dead.

Author: AutomatedTester

.bazelrc

@@ -94,7 +94,16 @@ common:linux --host_platform=//:local_linux_gnu
 # The LLVM toolchain doesn't ship libgcc_s; this stub satisfies Rust's
 # glibc stdlib link dependency when LLVM is the host C++ toolchain.
 common:linux --@llvm//config:experimental_stub_libgcc_s=True
-common:windows --host_platform=//:local_windows_msvc
+# Pin both the host (exec) and target platform to the gnullvm Windows
+# platform. Pinning only --host_platform leaves the target platform as
+# Bazel's auto-detected `x64_windows`, which lacks the gnullvm ABI / msvcrt
+# constraints. That makes the target-resolved Rust toolchain a different
+# variant than the exec-resolved one, so gnullvm proc-macro DLLs (e.g.
+# scroll_derive, time_macros) built in the exec config can't be loaded by
+# the target rustc and fail with `E0463: can't find crate`. Pinning both
+# (as the RBE config already does) keeps the whole build on one toolchain.
+common:windows --host_platform=//:local_windows_gnullvm
+common:windows --platforms=//:local_windows_gnullvm
 build:linux --workspace_status_command=scripts/build-info.sh
 build:macos --workspace_status_command=scripts/build-info.sh
 build:windows --workspace_status_command="powershell.exe scripts/build-info.ps1"

BUILD.bazel

@@ -141,25 +141,6 @@ platform(
     parents = ["@platforms//host"],
 )
 
-# Native Windows host platform. Used as `--host_platform` on Windows
-# runners so native rust builds go through `x86_64-pc-windows-msvc` (which
-# the Windows runners have installed as part of Visual Studio) rather
-# than `x86_64-pc-windows-gnullvm`. The gnullvm path drags in LLVM's
-# bootstrap-process-wrapper Starlark transition, which puts
-# `process_wrapper` in a different exec config than proc-macro deps and
-# trips rustc with `can't find crate for time_macros / scroll_derive`
-# style errors. Cross-compile targets in //rust still transition to the
-# gnullvm rules_rs platforms so non-Windows hosts can produce PE binaries
-# without a Windows SDK.
-platform(
-    name = "local_windows_msvc",
-    constraint_values = [
-        "@llvm//constraints/windows/abi:msvc",
-        "@llvm//constraints/windows/crt:msvcrt",
-    ],
-    parents = ["@platforms//host"],
-)
-
 buildifier(
     name = "buildifier",
     lint_mode = "fix",

rust/BUILD.bazel

@@ -65,10 +65,11 @@ alias(
         "//common:linux_x86_64": ":selenium-manager-linux-x86_64",
         "//common:macos_aarch64": ":selenium-manager-macos-aarch64",
         "//common:macos_x86_64": ":selenium-manager-macos-x86_64",
-        # On Windows hosts platform_transition_binary hits a process_wrapper /
-        # proc-macro exec-config hash divergence that prevents proc-macro DLLs
-        # from being found.  Fall back to the native rust_binary directly; on
-        # a gnullvm host this already produces the correct gnullvm PE binary.
+        # A Windows host is pinned to the gnullvm target platform (see the
+        # --platforms setting in .bazelrc), so the native rust_binary already
+        # builds the correct gnullvm PE binary. Using it directly avoids an
+        # unnecessary platform_transition_binary (and its -ST- exec config)
+        # on the host's own architecture.
         "//common:windows_aarch64": ":_selenium-manager-bin",
         "//common:windows_x86_64": ":_selenium-manager-bin",
     }),