rust-lang/cargo · error · anyhow::Error

lock file version `{n}` requires `-Znext-lockfile-bump`

Error message

lock file version `{n}` requires `-Znext-lockfile-bump`

What it means

Thrown by `into_resolve` while parsing `Cargo.lock`: the lockfile declares `version = 5`, but Cargo only accepts V5 when both nightly features are allowed (`gctx().nightly_features_allowed`) and the `-Znext-lockfile-bump` unstable flag is passed. Without the flag, a V5 lockfile is refused to prevent silent behavior divergence between stable and nightly.

Source

Thrown at src/resolver/encode.rs:149

/// dependencies do not know the difference between regular/dev/build
/// dependencies, so they are not filled in. It also does not include
/// `features`. Care should be taken when using this Resolve. One of the
/// primary uses is to be used with `resolve_with_previous` to guide the
/// resolver to create a complete Resolve.
pub fn into_resolve(
    resolve: TomlLockfile,
    original: &str,
    ws: &Workspace<'_>,
) -> CargoResult<Resolve> {
    let path_deps: HashMap<String, HashMap<semver::Version, SourceId>> = build_path_deps(ws)?;
    let mut checksums = HashMap::default();

    let mut version = match resolve.version {
        Some(n @ 5) if ws.gctx().nightly_features_allowed => {
            if ws.gctx().cli_unstable().next_lockfile_bump {
                ResolveVersion::V5
            } else {
                anyhow::bail!("lock file version `{n}` requires `-Znext-lockfile-bump`");
            }
        }
        Some(4) => ResolveVersion::V4,
        Some(3) => ResolveVersion::V3,
        Some(n) => bail!(
            "lock file version `{}` was found, but this version of Cargo \
             does not understand this lock file, perhaps Cargo needs \
             to be updated?",
            n,
        ),
        // Historically Cargo did not have a version indicator in lock
        // files, so this could either be the V1 or V2 encoding. We assume
        // an older format is being parsed until we see so otherwise.
        None => ResolveVersion::V1,
    };

    let packages = {
        let mut packages = resolve.package.unwrap_or_default();

View on GitHub (pinned to 0e07a15537)

Solutions

1. Run with the nightly toolchain and the unstable flag: `cargo +nightly -Znext-lockfile-bump build`.
2. Upgrade your Cargo/Rust toolchain to a version that stabilizes V5 lockfiles.
3. Delete `Cargo.lock` and regenerate it with your current Cargo (only if dependency reproducibility across the team is not a concern).
4. Pin the team to a single Rust/Cargo version to avoid lockfile-version churn.

Example fix

# before (stable cargo)
cargo build
# after
cargo +nightly -Znext-lockfile-bump build

# Pin the toolchain so Cargo.lock version stays consistent across the team:
# rust-toolchain.toml
[toolchain]
channel = "1.75"  # or a nightly that supports the needed lockfile version

# Detect V5 lockfiles before building:
grep -q '^version = 5' Cargo.lock && echo 'needs -Znext-lockfile-bump or newer Cargo'

When it happens

Trigger: Opening a project whose `Cargo.lock` was generated by a newer/nightly Cargo that wrote `version = 5`, using a Cargo build that lacks the `next-lockfile_bump` unstable feature. The `match` arm `Some(n @ 5)` with `nightly_features_allowed` true but `cli_unstable().next_lockfile_bump` false bails.

Common situations: Switching between stable and nightly toolchains; CI using stable Rust against a repo committed by a nightly user; checking out a repo whose lockfile was auto-bumped by a newer Cargo; downgrading Cargo after an upgrade.

Related errors

• lock file version `{current_version:?}` requires `-Znext-loc
• not implemented
• invalid character `+` in dependency name: `+{toolchain}`
• invalid character `+` in package name: `+{toolchain}` Us
• missing crate name before '@'

AI-assisted analysis of rust-lang/cargo@0e07a15537 (2026-08-06). Data as JSON: /data/errors/cd75bc3cf7a20a5f.json. Report an issue: GitHub.