cargo-chef 0.1.69 produces duplicate target in `xplr` crate
For context, we use cargo-chef for building Rust packages in Brioche (see rust/package.bri). After we upgraded from cargo-chef v0.1.68 to v0.1.70, our build of the package xplr started failing. I was able to reproduce it locally by checking out xplr@a82ea6a and using cargo-chef like this:
cargo chef prepare --recipe-path recipe.json
cargo chef cook --recipe-path recipe.json --no-build
I narrowed it down to a regression introduced in 0.1.69. Between 0.1.68 and 0.1.69, cargo-chef started introducing a duplicate [[examples]] target within Cargo.toml. Here's a diff between the Cargo.toml produced by cargo-chef between 0.1.68 and 0.1.69:
diff --git a/Cargo.toml b/Cargo.toml
index b4459a8..7d69c39 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -1,10 +1,11 @@
-test = []
-
[[bin]]
+path = "src/bin/xplr.rs"
name = "xplr"
plugin = false
proc-macro = false
+edition = "2021"
required-features = []
+crate-type = ["bin"]
[[bench]]
path = "./benches/criterion.rs"
@@ -12,7 +13,18 @@ name = "criterion"
plugin = false
proc-macro = false
harness = false
+edition = "2021"
+required-features = []
+crate-type = ["bin"]
+
+[[bench]]
+path = "benches/criterion.rs"
+name = "criterion"
+plugin = false
+proc-macro = false
+edition = "2021"
required-features = []
+crate-type = ["bin"]
[[example]]
path = "examples/run.rs"
@@ -21,6 +33,7 @@ plugin = false
proc-macro = false
edition = "2021"
required-features = []
+crate-type = ["bin"]
[package]
name = "xplr"
@@ -120,7 +133,7 @@ plugin = false
proc-macro = false
edition = "2021"
required-features = []
-crate-type = ["rlib"]
+crate-type = ["lib"]
[profile.release]
lto = true
This duplicate section causes Cargo commands to fail with the following error:
error: failed to parse manifest at `/path/to/xplr/Cargo.toml`
Caused by:
found duplicate bench name criterion, but all bench targets must have a unique name
The root of the issue is path = "./benches/criterion.rs".
If you change it to path = "benches/criterion.rs" it should work as expected.
On our side, I'll push a fix in cargo_manifest to handle this case too.