Skip to content

Docker: copy vendor/ and pin rustc 1.95.0 - #272

Merged
AdaWorldAPI merged 1 commit into
masterfrom
claude/dockerfile-vendor-and-toolchain
Jul 30, 2026
Merged

Docker: copy vendor/ and pin rustc 1.95.0#272
AdaWorldAPI merged 1 commit into
masterfrom
claude/dockerfile-vendor-and-toolchain

Conversation

@AdaWorldAPI

@AdaWorldAPI AdaWorldAPI commented Jul 30, 2026

Copy link
Copy Markdown
Owner

Two bugs, both pre-existing, the second hidden behind the first.

1 — vendor/ was never copied

The root manifest has [patch.crates-io] chacha20 = { path = "vendor/chacha20" }, and both Dockerfiles do a selective COPYCargo.toml, crates/, src/, examples/, benches/ — that never included vendor/.

Cargo resolves [patch] entries while loading the manifest, before features and before target selection. So this isn't a link-time miss; the build dies at parse:

error: failed to load source for dependency `chacha20`
Caused by: Unable to update /app/vendor/chacha20
Caused by: failed to read `/app/vendor/chacha20/Cargo.toml`

vendor/chacha20 is tracked (18 files), isn't gitignored, and .dockerignore doesn't exclude vendor/ — the directory was simply never listed. The patch arrived in 2539cad without the Dockerfiles being updated alongside it.

This is the same failure class as the examples//benches/ comment already in the file — which exists because this happened once before. A selective-COPY Dockerfile has to be updated whenever a path source is added to the manifest, and the new comment says so explicitly.

2 — The image pinned rustc 1.94.0 for a crate that requires 1.95

source says
Cargo.toml:6 rust-version = "1.95"
rust-toolchain.toml channel = "1.95.0"
Dockerfile:24 installs 1.94.0 and asserts it

This would have been the very next failure after fixing (1), and was invisible until then.

rust-toolchain.toml is deliberately not copied into the image — rustup would fetch a second toolchain at build time — so the Dockerfile pin is the only thing keeping the image in step with the repo. There's now a comment saying that and telling the next person to bump it when the toolchain moves.

Verification

No Docker daemon in this environment, so I reproduced the context exactly: a directory populated with precisely the Dockerfile's COPY list.

before, old COPY set cargo metadataexit 101, the identical error
after, with vendor/ cargo metadataexit 0

Then all three of the Dockerfile's RUN steps, on 1.95.0, under the image's RUSTFLAGS="-C target-cpu=x86-64-v3":

step result
cargo build --release Finished, 43.21s
cargo build --release --features jit-native Finished, 45.99s
cargo test --release --lib -- hpc:: 1732 passed, 0 failed

Not verified: an actual docker build. The simulation reproduces the reported failure byte-for-byte, clears it, and exercises every RUN line — but it does not cover anything specific to the debian base image or the apt layer.


Generated by Claude Code

Summary by CodeRabbit

  • Chores
    • Updated the Rust toolchain used in standard and AVX-512 container builds to version 1.95.0.
    • Added build verification to confirm the expected Rust version.
    • Improved container builds by including vendored dependencies required during dependency resolution.

Two bugs, both pre-existing, the second hidden behind the first.

1. vendor/ was never copied

The root manifest has `[patch.crates-io] chacha20 = { path = "vendor/chacha20" }`,
and both Dockerfiles do a selective COPY -- Cargo.toml, crates/, src/,
examples/, benches/ -- that never included vendor/. Cargo resolves patch entries
while LOADING THE MANIFEST, before features and before target selection, so this
is not a link-time miss; the build dies at parse:

  error: failed to load source for dependency `chacha20`
  Caused by: Unable to update /app/vendor/chacha20
  Caused by: failed to read `/app/vendor/chacha20/Cargo.toml`

vendor/chacha20 is tracked (18 files) and not gitignored, and .dockerignore does
not exclude vendor/ -- the directory simply was never listed. The patch arrived
in 2539cad without the Dockerfiles being updated alongside it. Same failure
class as the examples/benches note already in the file, which exists because
this happened once before.

2. The image pinned rustc 1.94.0 for a crate that requires 1.95

Cargo.toml says `rust-version = "1.95"` and rust-toolchain.toml says
channel = "1.95.0", but the Dockerfiles installed 1.94.0 and asserted it. This
would have been the very next failure after fixing (1) and was invisible until
then. rust-toolchain.toml is deliberately not copied into the image -- rustup
would fetch a second toolchain at build time -- so the Dockerfile pin is the only
thing keeping the image in step with the repo, and there is now a comment saying
so and telling the next person to bump it when the toolchain moves.

Verified by reproducing the Docker context exactly (no daemon available): a
directory populated with precisely the Dockerfile's COPY list.

  before, old COPY set:  cargo metadata -> exit 101, the identical error
  after,  with vendor/:  cargo metadata -> exit 0

then all three of the Dockerfile's RUN steps, on 1.95.0, with the image's
RUSTFLAGS="-C target-cpu=x86-64-v3":

  cargo build --release                        Finished, 43.21s
  cargo build --release --features jit-native   Finished, 45.99s
  cargo test --release --lib -- hpc::           1732 passed, 0 failed

Not verified: an actual `docker build`. No daemon in this environment. The
simulation reproduces the reported failure byte-for-byte and clears it, and it
exercises every RUN line, but it does not cover anything specific to the debian
base image or the apt layer.

Claude-Session: https://claude.ai/code/session_01VdfbkUCBbtZhy3yjSfCDHp
@coderabbitai

coderabbitai Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 26490c61-e39a-486f-869c-9fa1dfb3d4ac

📥 Commits

Reviewing files that changed from the base of the PR and between 6b5ca21 and 7988da6.

📒 Files selected for processing (2)
  • Dockerfile
  • Dockerfile.avx512

📝 Walkthrough

Walkthrough

Docker build stages are updated to Rust 1.95.0, verify the installed compiler version, copy vendored dependencies for Cargo patch resolution, and report the new version in runtime checks.

Changes

Rust build image updates

Layer / File(s) Summary
Rust 1.95.0 toolchain and verification
Dockerfile, Dockerfile.avx512
Both builder stages pin Rust 1.95.0 with rustc assertions, and final runtime messages report Rust 1.95.0.
Vendored dependency build context
Dockerfile
The builder copies vendor/, with comments describing Cargo’s [patch.crates-io] path resolution during manifest loading.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: claude

Poem

I’m a bunny with a builder bright,
Rust hops to one-nine-five tonight.
Vendor paths are tucked inside,
Cargo finds them side by side.
Containers cheer: “Build verified!”


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@AdaWorldAPI
AdaWorldAPI marked this pull request as ready for review July 30, 2026 18:58
@AdaWorldAPI
AdaWorldAPI merged commit bbbab0d into master Jul 30, 2026
20 of 21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants