New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multiple path dependencies with the same name confuses the resolver #13405
Comments
(Apologies for not having something more reduced, can try to do so if needed, though might take a bit) |
Thanks for the report! I believe I have a partial understanding of the problem. The following is a test for cargo's testsuite that demonstrates the issue: #[cargo_test]
fn patched_reexport_stays_locked() {
// Patch example where you emulate a semver-incompatible patch via a re-export.
// Testing an issue where the lockfile does not stay locked after a new version is published.
Package::new("bar", "1.0.0").publish();
Package::new("bar", "2.0.0").publish();
Package::new("bar", "3.0.0").publish();
let p = project()
.file(
"Cargo.toml",
r#"
[workspace]
[package]
name = "foo"
[dependencies]
bar1 = {package="bar", version="1.0.0"}
bar2 = {package="bar", version="2.0.0"}
[patch.crates-io]
bar1 = { package = "bar", path = "bar-1-as-3" }
bar2 = { package = "bar", path = "bar-2-as-3" }
"#,
)
.file("src/lib.rs", "")
.file(
"bar-1-as-3/Cargo.toml",
r#"
[package]
name = "bar"
version = "1.0.999"
[dependencies]
bar = "3.0.0"
"#,
)
.file("bar-1-as-3/src/lib.rs", "")
.file(
"bar-2-as-3/Cargo.toml",
r#"
[package]
name = "bar"
version = "2.0.999"
[dependencies]
bar = "3.0.0"
"#,
)
.file("bar-2-as-3/src/lib.rs", "")
.build();
p.cargo("tree")
.with_stdout(
"\
foo v0.0.0 ([ROOT]/foo)
├── bar v1.0.999 ([ROOT]/foo/bar-1-as-3)
│ └── bar v3.0.0
└── bar v2.0.999 ([ROOT]/foo/bar-2-as-3)
└── bar v3.0.0
",
)
.run();
fs::copy(
p.root().join("Cargo.lock"),
p.root().join("Cargo.lock.orig"),
)
.unwrap();
Package::new("bar", "3.0.1").publish();
p.cargo("tree")
.with_stdout(
"\
foo v0.0.0 ([ROOT]/foo)
├── bar v1.0.999 ([ROOT]/foo/bar-1-as-3)
│ └── bar v3.0.0
└── bar v2.0.999 ([ROOT]/foo/bar-2-as-3)
└── bar v3.0.0
",
)
.run();
assert_eq!(p.read_file("Cargo.lock"), p.read_file("Cargo.lock.orig"));
} The problem I believe is here. When loading the original |
@rustbot claim |
Hi, I copy the test into the cargo repo and get this output
Hmm, the test case failed to run, and I think the final code fix is to get the use case to pass |
…es. r=supply-chain-reviewers Because fallible_collections pulls hashbrown 0.13, we also upgrade hashlink to 0.8.2, which updates to that version as well. Those were the last two uses of hashbrown 0.12, so we can update the fake hashbrown 0.12 to 0.13. We could skip the upgrade of hashlink, but that would leave us with two fake hashbrowns, and we'd hit rust-lang/cargo#13405 Differential Revision: https://phabricator.services.mozilla.com/D209317
…es. r=supply-chain-reviewers Because fallible_collections pulls hashbrown 0.13, we also upgrade hashlink to 0.8.2, which updates to that version as well. Those were the last two uses of hashbrown 0.12, so we can update the fake hashbrown 0.12 to 0.13. We could skip the upgrade of hashlink, but that would leave us with two fake hashbrowns, and we'd hit rust-lang/cargo#13405 Differential Revision: https://phabricator.services.mozilla.com/D209317
I recently published a new rust-bindgen version (0.69.4), and that caused some Firefox CI jobs to fail (https://bugzilla.mozilla.org/show_bug.cgi?id=1878575), because some CI checks that run
cargo metadata
ended up touching the lockfile and updating bindgen.The relevant bits that seem to be needed to reproduce this is a local crate for an older version of the crate.
To reproduce:
git clone https://github.com/mozilla/gecko-dev
cd gecko-dev
git reset --hard 9d8d867dac5d35156a51ef21fe7b46f573aaabef
cargo metadata
Somehow, the lockfile changes to
bindgen 0.69.4
even though the lockfile specifies 0.69.2The text was updated successfully, but these errors were encountered: