Pin one Rust toolchain for the dev shell and CI - #47
Conversation
The dev shell and CI resolved toolchains from independent clocks: fenix "stable" moves on nix flake update (was 1.95), while dtolnay/rust-toolchain@stable moves on every Rust release (1.97). The gap meant CI could lint code the dev shell's clippy had never seen, which is exactly how PR #46 went red on untouched code. rust-toolchain.toml is now the single pin: the flake builds the dev shell from it (fenix fromToolchainFile) and CI installs from it via plain rustup, so neither side can move alone. Bumping the channel means updating the toml plus the sha256 next to it (build once with lib.fakeSha256 to learn the new one), and possibly the fenix input. Also disables nix's fortify hardening in the shell: combined with cargo's -O0 it makes glibc emit a #warning that jemalloc's -Werror configure probes turn into "cannot determine return type of strerror_r", so cargo check never got off the ground in the shell. just ci now passes in the dev shell under the same clippy CI runs. The napi release matrix keeps its own RUST_VERSION pin (1.85) in CI.yml; prebuilt binaries are a separate decision from lint parity.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 92d7af45b0
ℹ️ 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".
| # the MSRV for downstream consumers; the napi release builds pin their own | ||
| # RUST_VERSION in CI.yml. | ||
| [toolchain] | ||
| channel = "1.97.0" |
There was a problem hiding this comment.
In the inspected .github/workflows/CI.yml build matrix (lines 7, 84-146, and 164-169), release builds deliberately install/default Rust 1.85, but this repository-level rust-toolchain.toml overrides that default: rustup help override states that any rustc or cargo run inside an overridden directory invokes the override toolchain. Consequently, yarn build selects 1.97 despite rustup default 1.85; non-host targets installed by the action only for 1.85 are then unavailable under 1.97, so cross-build jobs can fail with a missing-target error, while other artifacts silently stop using the release pin. Set RUSTUP_TOOLCHAIN, invoke cargo +1.85, or otherwise prevent this lint/dev override from applying to the build matrix.
Useful? React with 👍 / 👎.
Codex caught what the toolchain pin broke: rust-toolchain.toml is a rustup directory override, so it outranked the release matrix's `rustup default 1.85` and every build ran under 1.97, whose cross-targets were never installed (android, windows, and darwin jobs failed on missing targets; the docker jobs would have followed). RUSTUP_TOOLCHAIN outranks the directory override, so the host Build step sets it and the docker run forwards it, both derived from the existing RUST_VERSION. The check job is untouched and keeps following the toml.
1 participant
The dev shell and CI resolved toolchains from independent clocks: fenix "stable" moves on nix flake update (was 1.95), while dtolnay/rust-toolchain@stable moves on every Rust release (1.97). The gap meant CI could lint code the dev shell's clippy had never seen, which is exactly how PR #46 went red on untouched code.
rust-toolchain.toml is now the single pin: the flake builds the dev shell from it (fenix fromToolchainFile) and CI installs from it via plain rustup, so neither side can move alone. Bumping the channel means updating the toml plus the sha256 next to it (build once with lib.fakeSha256 to learn the new one), and possibly the fenix input.
Also disables nix's fortify hardening in the shell: combined with cargo's -O0 it makes glibc emit a #warning that jemalloc's -Werror configure probes turn into "cannot determine return type of strerror_r", so cargo check never got off the ground in the shell.
just ci now passes in the dev shell under the same clippy CI runs. The napi release matrix keeps its own RUST_VERSION pin (1.85) in CI.yml; prebuilt binaries are a separate decision from lint parity.