rust-lang/cargo · error

jobs may not be 0

Error message

jobs may not be 0

What it means

In BuildConfig::new (build_config.rs:89-90), the `jobs` value is parsed from `-j <n>` or `build.jobs` config. An explicit integer of `0` is invalid because zero parallel jobs would build nothing, so Cargo bails with `jobs may not be 0`. Negative values are allowed (treated as relative to default parallelism) but zero is not.

Source

Thrown at src/compiler/build_config.rs:90

        jobs: Option<JobsConfig>,
        keep_going: bool,
        requested_targets: &[String],
        intent: UserIntent,
    ) -> CargoResult<BuildConfig> {
        let cfg = gctx.build_config()?;
        let requested_kinds = CompileKind::from_requested_targets(gctx, requested_targets)?;
        if jobs.is_some() && gctx.jobserver_from_env().is_some() {
            gctx.shell().warn(
                "a `-j` argument was passed to Cargo but Cargo is \
                 also configured with an external jobserver in \
                 its environment, ignoring the `-j` parameter",
            )?;
        }
        let jobs = match jobs.or(cfg.jobs.clone()) {
            None => default_parallelism()?,
            Some(value) => match value {
                JobsConfig::Integer(j) => match j {
                    0 => anyhow::bail!("jobs may not be 0"),
                    j if j < 0 => (default_parallelism()? as i32 + j).max(1) as u32,
                    j => j as u32,
                },
                JobsConfig::String(j) => match j.as_str() {
                    "default" => default_parallelism()?,
                    _ => {
                        anyhow::bail!(format!(
                            "could not parse `{j}`. Number of parallel jobs should be `default` or a number."
                        ))
                    }
                },
            },
        };

        // If sbom flag is set, it requires the unstable feature
        let sbom = match (cfg.sbom, gctx.cli_unstable().sbom) {
            (Some(sbom), true) => sbom,
            (Some(_), false) => {

View on GitHub (pinned to 0e07a15537)

Solutions

  1. Pass a positive integer: `cargo build -j 4`.
  2. Omit `-j` to let Cargo use default parallelism (number of CPUs).
  3. Use `-j default` or `build.jobs = "default"` explicitly.
  4. Fix the CI variable that produced 0 (e.g. fall back to `nproc` when unset).

Example fix

// before
$ CARGO_BUILD_JOBS=0 cargo build
error: jobs may not be 0

// after
$ cargo build -j 4
Defensive patterns

Strategy: validation

Validate before calling

match jobs {
    Some(JobsConfig::Integer(0)) => return Err("jobs may not be 0"),
    Some(JobsConfig::Integer(j)) if j < 0 => { /* relative */ }
    _ => {}
}

Type guard

fn jobs_is_valid(j: i64) -> bool {
    j != 0
}

Prevention

When it happens

Trigger: Passing `cargo build -j 0`, or setting `[build] jobs = 0` in config, or a computed job count that resolves to 0.

Common situations: CI scripts computing `-j` from a CPU count variable that is unset/0; `CARGO_BUILD_JOBS=0` in the environment; misconfigured `build.jobs`.

Related errors


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