rust-lang/cargo · error
could not parse ` `. Number of parallel jobs should be…
Error message
could not parse `{j}`. Number of parallel jobs should be `default` or a number. What it means
Cargo failed to parse the `jobs` setting (configures build parallelism via `build.jobs` or `--jobs`). The value was a string that was neither the literal `"default"` nor parseable as an integer. Cargo accepts only `JobsConfig::Integer` or the string `"default"`; any other string falls through to this bail.
Solutions
- Set `build.jobs` to an integer (e.g. `jobs = 4`) or the literal string `default` in `.cargo/config.toml`.
- If using an env var, ensure `CARGO_BUILD_JOBS` holds a plain integer or omit it to use default parallelism.
- Pass `--jobs N` (integer) or `--jobs default` on the command line.
- Audit shell scripts that interpolate `${JOBS}` and guard against empty/non-numeric values before exporting.
Example fix
// before (config.toml) [build] jobs = "auto" // after [build] jobs = "default" // or jobs = 4
Defensive patterns
Strategy: validation
Validate before calling
// Validate a jobs value before handing it to Cargo config
fn is_valid_jobs(v: &str) -> bool {
v == "default" || v.parse::<i32>().map(|n| n != 0).unwrap_or(false)
} Type guard
fn is_jobs_string(v: &str) -> bool { v == "default" }
fn is_jobs_int(v: &serde_json::Value) -> bool { v.is_i64() && v.as_i64().map(|n| n != 0).unwrap_or(false) } Try / catch
match cargo::BuildConfig::from_env() {
Ok(cfg) => cfg,
Err(e) if e.to_string().contains("could not parse") => { eprintln!("jobs must be `default` or an integer"); default_config() },
Err(e) => return Err(e),
} Prevention
- Always store `build.jobs` as a bare TOML integer or the literal string `default`.
- In shell scripts, default `CARGO_BUILD_JOBS` to empty rather than a placeholder word.
- Unit-test config generators that emit the jobs value.
When it happens
Trigger: Setting `build.jobs = "auto"` (or `"max"`, `"all"`, `"8"` as a quoted string that isn't the literal `default`) in config, or passing `--jobs foo` / `CARGO_BUILD_JOBS=foo`. Also triggered by a TOML config that stores jobs as a non-integer, non-`default` string.
Common situations: Users assume Cargo understands words like `auto`/`max`/`unlimited`; misconfigured CI templates that set `CARGO_BUILD_JOBS="${N}"` with an empty or non-numeric N; YAML-to-TOML migrations that quote numbers.
Related errors
- can't find library ` `, rename file to `src/lib.rs` or…
- cannot mix `proc-macro` crate type with others
- cannot specify both `metabuild` and `build`
- config.json not found
- could not find cargo home dir
AI-assisted analysis of rust-lang/cargo@eb98b54bc9 (2026-08-11).
Data as JSON: /api/errors/79041acf8f9a18c0.
Report an issue: GitHub.
Appendix: source
Thrown at src/compiler/build_config.rs:97
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) => {
gctx.shell()
.warn("ignoring 'sbom' config, pass `-Zsbom` to enable it")?;
false
}
(None, _) => false,
};
View on GitHub (pinned to eb98b54bc9)