ci: run Windows argument-comment-lint via native Bazel

[bolinfest]

Why

Follow-up to #16106.

argument-comment-lint already runs as a native Bazel aspect on Linux and macOS, but Windows is still the long pole in rust-ci. To move Windows onto the same native Bazel lane, the toolchain split has to let exec-side helper binaries build in an MSVC environment while still linting repo crates as windows-gnullvm.

Pushing the Windows lane onto the native Bazel path exposed a second round of Windows-only issues in the mixed exec-toolchain plumbing after the initial wrapper/target fixes landed.

What Changed

• keep the Windows lint lanes on the native Bazel/aspect path in rust-ci.yml and rust-ci-full.yml
• add a dedicated local_windows_msvc platform for exec-side helper binaries while keeping local_windows as the windows-gnullvm target platform
• patch rules_rust so repository_set(...) preserves explicit exec-platform constraints for the generated toolchains, keep the Windows-specific bootstrap/direct-link fixes needed for the nightly lint driver, and expose exec-side rustc-dev .rlibs to the MSVC sysroot
• register the custom Windows nightly toolchain set with MSVC exec constraints while still exposing both x86_64-pc-windows-msvc and x86_64-pc-windows-gnullvm targets
• enable dev_components on the custom Windows nightly repository set so the MSVC exec helper toolchain actually downloads the compiler-internal crates that clippy_utils needs
• teach run-argument-comment-lint-bazel.sh to enumerate concrete Windows Rust rules, normalize the resulting labels, and skip explicitly requested incompatible targets instead of failing before the lint run starts
• patch rules_rust build-script env propagation so exec-side windows-msvc helper crates drop forwarded MinGW include and linker search paths as whole flag/path pairs instead of emitting malformed CFLAGS, CXXFLAGS, and LDFLAGS
• export the Windows VS/MSVC SDK environment in setup-bazel-ci and pass the relevant variables through run-bazel-ci.sh via --action_env / --host_action_env so Bazel build scripts can see the MSVC and UCRT headers on native Windows runs
• add inline comments to the Windows setup-bazel-ci MSVC environment export step so it is easier to audit how vswhere, VsDevCmd.bat, and the filtered GITHUB_ENV export fit together
• patch aws-lc-sys to skip its standalone memcmp probe under Bazel windows-msvc build-script environments, which avoids a Windows-native toolchain mismatch that blocked the lint lane before it reached the aspect execution
• patch aws-lc-sys to prefer its bundled prebuilt-nasm objects for Bazel windows-msvc build-script runs, which avoids missing generated-src/win-x86_64/*.asm runfiles in the exec-side helper toolchain
• annotate the Linux test-only callsites in codex-rs/linux-sandbox and codex-rs/core that the wider native lint coverage surfaced

Patches

This PR introduces a large patch stack because the Windows Bazel lint lane currently depends on behavior that upstream dependencies do not provide out of the box in the mixed windows-gnullvm target / windows-msvc exec-toolchain setup.

• Most of the rules_rust patches look like upstream candidates rather than OpenAI-only policy. Preserving explicit exec-platform constraints, forwarding the right MSVC/UCRT environment into exec-side build scripts, exposing exec-side rustc-dev artifacts, and keeping the Windows bootstrap/linker behavior coherent all look like fixes to the Bazel/Rust integration layer itself.
• The two aws-lc-sys patches are more tactical. They special-case Bazel windows-msvc build-script environments to avoid a memcmp probe mismatch and missing NASM runfiles. Those may be harder to upstream as-is because they rely on Bazel-specific detection instead of a general Cargo/build-script contract.
• Short term, carrying these patches in-tree is reasonable because they unblock a real CI lane and are still narrow enough to audit. Long term, the goal should not be to keep growing a permanent local fork of either dependency.
• My current expectation is that the rules_rust patches are less controversial and should be broken out into focused upstream proposals, while the aws-lc-sys patches are more likely to be temporary escape hatches unless that crate wants a more general hook for hermetic build systems.

Suggested follow-up plan:

1. Split the rules_rust deltas into upstream-sized PRs or issues with minimized repros.
2. Revisit the aws-lc-sys patches during the next dependency bump and see whether they can be replaced by an upstream fix, a crate upgrade, or a cleaner opt-in mechanism.
3. Treat each dependency update as a chance to delete patches one by one so the local patch set only contains still-needed deltas.

Verification

• ./.github/scripts/run-argument-comment-lint-bazel.sh --config=argument-comment-lint --keep_going
• RUNNER_OS=Windows ./.github/scripts/run-argument-comment-lint-bazel.sh --nobuild --config=argument-comment-lint --platforms=//:local_windows --keep_going
• cargo test -p codex-linux-sandbox
• cargo test -p codex-core shell_snapshot_tests
• just argument-comment-lint

References

• build: migrate argument-comment-lint to a native Bazel aspect #16106

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c67cf0b9c4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Include manual unit-test targets in Bazel lint run

Switching this job to bazel build ... //codex-rs/... drops lint coverage for unit-test crates because Bazel wildcard patterns exclude targets tagged manual, and our unit-test rust_test targets are tagged manual in defs.bzl (tags = test_tags + ["manual"]). The previous wrapper path defaulted to Cargo --all-targets, so test-only call sites were checked; with this change, uncommented literal arguments inside unit tests can pass CI undetected unless those targets are explicitly listed.

Useful? React with 👍 / 👎.