rust-lang/cargo · error
`[project]` is not supported as of the 2024 Edition, please…
Error message
`[project]` is not supported as of the 2024 Edition, please use `[package]`
What it means
Thrown when a manifest contains a [project] section and the resolved edition is 2024 or later. Historically [project] was an alias for [package]; as of the 2024 edition it is removed entirely (a hard error). For editions before 2024, the same condition only emits a deprecation warning. The check uses original_toml.project.is_some() and compares Edition::Edition2024 <= edition.
Solutions
- Rename the [project] section header to [package] in Cargo.toml.
- If a tool generated the manifest, update its template to use [package].
- Run `cargo fix --edition` to migrate legacy fields when bumping editions.
Example fix
# before [project] name = "my-crate" version = "0.1.0" edition = "2024" # after [package] name = "my-crate" version = "0.1.0" edition = "2024"
Defensive patterns
Strategy: validation
Validate before calling
fn check_no_project_section_on_2024(toml: &str) -> Result<(), String> {
let v: toml::Value = toml::from_str(toml).map_err(|e| e.to_string())?;
let edition = v.get("package").or_else(|| v.get("project"))
.and_then(|p| p.get("edition")).and_then(|e| e.as_str())
.unwrap_or("2015");
if v.get("project").is_some() && edition >= "2024" {
return Err("rename [project] to [package] for edition 2024".into());
}
Ok(())
} Type guard
fn uses_package_not_project(toml: &toml::Value) -> bool {
toml.get("project").is_none() || toml.get("package").is_some()
} Prevention
- Always use [package], never [project], in new manifests.
- Run `cargo fix --edition` when upgrading to edition 2024.
- Audit manifests during edition migration for [project] sections.
When it happens
Trigger: A Cargo.toml with edition = "2024" (or unspecified defaulting to 2024) that uses [project] instead of [package]. Triggered during to_real_manifest validation.
Common situations: Upgrading a crate's edition to 2024 without renaming [project] to [package]. Very old manifests that predate the [package] standardization. Templates that still emit [project].
Related errors
- ` ` is unsupported as of the 2024 edition; instead use `…
- manifest is missing either a `[package]` or a `[workspace]`
- can only edit absolute paths, got
- can't find library ` `, rename file to `src/lib.rs` or…
- cannot mix `proc-macro` crate type with others
AI-assisted analysis of rust-lang/cargo@98a09e7e7d (2026-08-11).
Data as JSON: /api/errors/7ecf1711521411b5.
Report an issue: GitHub.
Appendix: source
Thrown at src/workspace/parser/mod.rs:1395
));
}
default_edition
};
if !edition.is_stable() {
let version = normalized_package
.normalized_version()
.expect("previously normalized")
.map(|v| format!("@{v}"))
.unwrap_or_default();
let hint = rust_version
.as_ref()
.map(|rv| format!("help: {package_name}{version} requires rust {rv}"));
features.require_with_hint(Feature::unstable_editions(), hint.as_deref())?;
}
if original_toml.project.is_some() {
if Edition::Edition2024 <= edition {
anyhow::bail!(
"`[project]` is not supported as of the 2024 Edition, please use `[package]`"
);
} else {
warnings.push(format!("`[project]` is deprecated in favor of `[package]`"));
}
}
if normalized_package.metabuild.is_some() {
features.require(Feature::metabuild())?;
}
if is_embedded {
let manifest::TomlManifest {
cargo_features: _,
package: _,
project: _,
badges: _,
features: _,View on GitHub (pinned to 98a09e7e7d)