2 Commits

• [codex] Upgrade rules_rs and llvm to latest BCR versions (#18397)

  ## Why
  This branch brings the Bazel module pins for `rules_rs` and `llvm` up to
  the latest BCR releases and aligns the root direct dependencies with the
  versions the module graph already resolves to.
  
  That gives us a few concrete wins:
  - picks up newer upstream fixes in the `rules_rs` / `rules_rust` stack,
  including work around repo-rule nondeterminism and default Cargo binary
  target generation
  - picks up test sharding support from the newer `rules_rust` stack
  ([hermeticbuild/rules_rust#13](https://github.com/hermeticbuild/rules_rust/pull/13))
  - picks up newer built-in knowledge for common system crates like
  `gio-sys`, `glib-sys`, `gobject-sys`, `libgit2-sys`, and `libssh2-sys`,
  which gives us a future path to reduce custom build-script handling
  - reduces local patch maintenance by dropping fixes that are now
  upstream and rebasing the remaining Windows patch stack onto a newer
  upstream base
  - removes the direct-dependency warnings from `bazel-lock-check` by
  making the root pins match the resolved graph
  
  ## What Changed
  - bump `rules_rs` from `0.0.43` to `0.0.58`
  - bump `llvm` from `0.6.8` to `0.7.1`
  - bump `bazel_skylib` from `1.8.2` to `1.9.0` so the root direct dep
  matches the resolved graph
  - regenerate `MODULE.bazel.lock` for the updated module graph
  - refresh the remaining Windows-specific patch stack against the newer
  upstream sources:
    - `patches/rules_rs_windows_gnullvm_exec.patch`
    - `patches/rules_rs_windows_exec_linker.patch`
    - `patches/rules_rust_windows_exec_std.patch`
    - `patches/rules_rust_windows_msvc_direct_link_args.patch`
  - remove patches that are no longer needed because the underlying fixes
  are upstream now:
    - `patches/rules_rs_delete_git_worktree_pointer.patch`
    - `patches/rules_rust_repository_set_exec_constraints.patch`
  
  ## Validation
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  zbarsky-openai · 2026-04-17 18:45:32 -04:00
  680c4102ae
• ci: run Windows argument-comment-lint via native Bazel (#16120)

  ## 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` `.rlib`s 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
  
  - #16106

  Michael Bolin · 2026-03-30 15:32:04 -07:00
  19f0d196d1