Check the lockfile change before blaming the new Rust compiler

Article · Derived state

The branch upgrades Rust and regenerates Cargo.lock. A test now fails. The issue gets titled “new compiler regression.”

Maybe it is. The branch also changed the code being compiled.

Before filing that conclusion, I would separate the toolchain change from the dependency change. The lockfile often contains the most useful clue in the diff.

Read what changed

Check which package versions changed, whether features changed, and whether a dependency now requires a newer Rust version. Native libraries and build dependencies can matter even when application source is unchanged.

Cargo describes resolution and the lockfile. The MSRV and resolver article explains how compiler-version compatibility can influence selection. A dependency graph is an input, not background scenery.

Do not fix the investigation by repeatedly running an unrestricted update. That keeps moving the target. Preserve the failing lockfile before changing anything else.

A real lockfile change during this batch

While these articles were being checked, the site's Content safety run reproduced a smaller version of this problem. The SQL fixture source had not changed. Its workflow still ran cargo generate-lockfile before verification.

That command selected crypto-bigint 0.7.9 instead of the committed 0.7.8. The database examples passed, but the job failed its check for uncommitted lockfile changes. The preserved artifact showed the version and checksum difference.

This was dependency-resolution drift. It was not evidence of a compiler regression. The workflow was changed to fetch the committed graph with cargo fetch --locked; tests still use the locked graph too. Updating that graph now needs its own reviewable change.

Compare only valid combinations

Use a small comparison matrix in CI:

The final row may be invalid because a new dependency needs the new compiler. Record that as an unsupported combination, not as evidence of a runtime regression.

Use locked dependency resolution for the comparison where appropriate. Record the compiler identity, target, feature set, profile, and relevant environment. A different feature selection can change the graph without an obvious version change.

The matrix does not require a huge benchmark campaign. Start with the smallest failing test or compilation case through the existing workflow. Broaden only when the evidence requires it.

Follow the variable that reproduces the failure

If the new compiler fails with the old graph while the previous compiler passes, reduce the compiler-sensitive case. Check diagnostics, edition settings, target differences, and documented changes before deciding it is a compiler bug.

If the new lockfile introduces the failure on a compatible toolchain, narrow the relevant package update. A temporary pin can help establish causation, but explain the reason and the condition for removing it.

If neither isolated change fails, investigate their interaction. Build scripts, conditional compilation, and MSRV-aware resolution can produce a genuinely combined case.

Avoid claiming that a clean build solved the cause merely because the symptom disappeared once. Keep the original graph and failing evidence available. Cache state is another variable to control, not an explanation by itself.

Leave a result the next person can use

The review should say which combination fails, which passes, and what evidence supports the conclusion. Link the relevant CI runs and keep a reduced reproduction when possible.

Sometimes the compiler really is responsible. A controlled comparison makes that report much stronger. Sometimes a dependency changed behaviour while the upgrade drew everyone's attention. Looking at the lockfile first can save a long investigation of code that was never at fault.

Preserve the small diff that establishes drift

The useful evidence in that run was a package version change, from crypto-bigint 0.7.8 to 0.7.9, accompanied by its registry checksum. The failure gate reported a changed lockfile after the examples had run. That supports a narrow conclusion: resolution changed an input that the repository expected to remain committed.

It does not establish a runtime defect in either package version. It also does not establish a Rust compiler regression. Both conclusions would need a different reproduction. Keeping those distinctions in the review prevents a housekeeping failure from becoming an inaccurate compatibility warning.

During the later fixtures, adding pinned gzip and signature dependencies required another deliberate lockfile update. That graph was resolved in GitHub CI, inspected, and committed. Normal verification then returned to locked fetches and tests. The exception had a concrete dependency reason and an end; it was not left as a resolver step that silently updates the graph on every check.

Record that boundary beside the fix. A future maintainer should be able to distinguish an approved dependency update from the unexpected mutation that originally failed the job.