warnings are denied by `build.warnings` configuration

Error message

warnings are denied by `build.warnings` configuration

What it means

Thrown by `cargo fetch` when `build.warnings` is set to `"deny"` in config (`.cargo/config.toml` or the `CARGO_BUILD_WARNINGS` env / `[build] warnings = "deny"`) AND the manifest-parse pass emitted one or more lint warnings (`lint_warning_count > 0`). Cargo treats the deny policy strictly: any warning during manifest parsing aborts the fetch instead of merely printing.

Solutions

Address the specific warning printed just before the bail — remove/replace the offending manifest key or field the parse pass flagged.
Temporarily relax the policy to inspect: `CARGO_BUILD_WARNINGS=warn cargo fetch`, or remove `warnings = "deny"` from `[build]` in `.cargo/config.toml`.
Pin the manifest to the schema the current cargo accepts — migrate deprecated keys per the cargo release notes / migration guide.
If the warning is from a dependency's manifest (rare in fetch), update or replace that dependency.

Example fix

# before — .cargo/config.toml
[build]
warnings = "deny"
# manifest has a deprecated key -> fetch aborts

# after — fix the warned field, OR relax
[build]
warnings = "warn"

Defensive patterns

Strategy: validation

Validate before calling

// Before enabling deny mode in CI, run a warn-mode pass to surface manifest lints.
// `cargo fetch` with CARGO_BUILD_WARNINGS=warn first; only flip to deny when count == 0.
fn should_deny(warning_count: usize) -> bool { warning_count == 0 }

Prevention

Introduce `build.warnings = "deny"` incrementally — first fix all existing warnings in warn mode.
After every cargo upgrade, run a warn-mode fetch/build and review new manifest lints before re-enabling deny.
Keep manifests free of deprecated keys; follow the cargo edition migration guide.
In CI, run the deny-mode step after a warn-mode diagnostic step so failures are explainable.

When it happens

Trigger: Setting `[build] warnings = "deny"` (or `CARGO_BUILD_WARNINGS=deny`) and running `cargo fetch`/`cargo build`/`cargo check` against a manifest that triggers a deprecation or lint warning during the parse pass — e.g. a deprecated manifest key, an unused `[badges]` entry, or a key slated for removal.

Common situations: Adopting strict warning policy in CI via `build.warnings = "deny"` then upgrading cargo, which newly warns on a previously-silent manifest field. Carrying a legacy `[badges]` table or `edition = "2015"` style fields. Switching a repo to deny-warnings after the manifest already has minor issues.

Related errors

AI-assisted analysis of rust-lang/cargo@42eee92bc9 (2026-08-11). Data as JSON: /api/errors/31b33ab44f7e05a0. Report an issue: GitHub.

Appendix: source

Thrown at src/ops/cargo_fetch.rs:91

    // If -Zbuild-std was passed, download dependencies for the standard library.
    if let Some(crates) = &gctx.cli_unstable().build_std {
        let (std_package_set, _, _) = standard_lib::resolve_std(
            ws,
            &mut data,
            &build_config,
            crates,
            &build_config.requested_kinds,
        )?;
        packages.add_set(std_package_set);
    }

    packages.get_many(to_download)?;
    crate::workspace::gc::auto_gc(gctx);

    if ws.gctx().warning_handling()? == WarningHandling::Deny
        && parse_pass_output.lint_warning_count > 0
    {
        anyhow::bail!("warnings are denied by `build.warnings` configuration")
    }

    Ok((resolve, packages))
}

View on GitHub (pinned to 42eee92bc9)