The slow codex-core rebuilds are dominated by debug-info codegen, not parsing
or type checking. On a warm-dependency package rebuild, the baseline
codex-core compile was about 39.5s wall / 38.9s rustc total, with
codegen_crate around 14.0s and LLVM_passes around 13.4s. Setting codex-core
to line-tables-only debug info brought that to about 27.2s wall / 26.7s rustc
total, with codegen_crate around 3.1s and LLVM_passes around 2.8s.
I also sampled other first-party crates instead of keeping a codex-core-only
package override. codex-app-server showed the same pattern: rustc total
dropped from 15.85s to 10.48s, while codegen_crate plus LLVM_passes dropped
from about 13.47s to 3.23s. codex-app-server-protocol had a smaller but still
real improvement, 16.05s to 14.58s total, and smaller crates showed modest
wins. That points to a workspace dev-profile policy rather than a
hand-maintained list of large crates.
Use `[profile.dev] debug = 1` so local dev builds keep line tables and useful
backtraces while avoiding full variable debug info. This can cause a one-time
rebuild because the Cargo dev profile hash changes, but subsequent rebuilds
avoid the expensive debug-info work.
Bazel does not read Cargo profiles for this setting. rules_rust derives
debuginfo from Bazel toolchain/compilation-mode settings and the current
fastbuild action already emitted `--codegen=debuginfo=0`. This change makes
the CI choice explicit for both target and exec-configuration Rust actions
with `-Cdebuginfo=0`.
Verification:
- `just bazel-lock-update`
- `just bazel-lock-check`
- `cargo check -p codex-core --lib`
- `cargo test -p codex-core --lib`
- Bazel `aquery --config=ci-linux` confirmed `--codegen=debuginfo=0` and
`-Cdebuginfo=0` for `//codex-rs/core:core`
Follow-up to https://github.com/openai/codex/pull/18178, where we said
the await-holding clippy rule would be enabled separately.
Enable `await_holding_lock` and `await_holding_invalid_type` after the
preceding commits fixed or explicitly documented the current offenders.
Michael Bolin