Fix cargo install with a semver metadata version.
#9467
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors: r+ Thanks for tracking this down! |
|
📌 Commit 9387a30 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
bors
added a commit
that referenced
this pull request
May 10, 2021
Bump index cache version to deal with semver metadata version mismatch. #9467 has uncovered an issue with how versions are handled in the index cache. When using a debug build of Cargo, it may panic due to the [cache contents changing](https://github.com/rust-lang/cargo/blob/5c455130b6001c7f54e872e161c27f6e996aff1f/src/cargo/sources/registry/index.rs#L606-L619). The particular problem I am running into is that the index has an entry for `openssl-src 110.0.0` and `110.0.0+1.1.0f`. This is due to an issue with crates.io where it allows publishing multiple versions with the same metadata (rust-lang/crates.io#1059). Cargos before #9467 would populate the index cache with two entries, both with version `110.0.0`. Afterwards, there are two separate entries (`110.0.0` and `110.0.0+1.1.0f`). The change here is to bump the index cache version so that new versions of cargo will clear the cache, and won't trigger the assertion. This may be a bit of a heavy-handed solution, as I think this only affects debug builds of cargo. However, I instantly started running into this problem, so I suspect it will be a real annoyance for anyone developing cargo. Happy to discuss other possible solutions.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 12, 2021
Update cargo 8 commits in e51522ab3db23b0d8f1de54eb1f0113924896331..070e459c2d8b79c5b2ac5218064e7603329c92ae 2021-05-07 21:29:52 +0000 to 2021-05-11 18:12:23 +0000 - Fix rustdoc warnings (rust-lang/cargo#9468) - Improve performance of git status check in `cargo package`. (rust-lang/cargo#9478) - Link to the new rustc tests chapter. (rust-lang/cargo#9477) - Bump index cache version to deal with semver metadata version mismatch. (rust-lang/cargo#9476) - Fix Url::into_string deprecation warning (rust-lang/cargo#9475) - Fix rust-lang/cargo#4482 and rust-lang/cargo#9449: set Fossil ignore and clean settings locally (rust-lang/cargo#9469) - Improve two error messages (rust-lang/cargo#9472) - Fix `cargo install` with a semver metadata version. (rust-lang/cargo#9467)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes an issue where
cargo install cargo-c --version 0.8.0+cargo-0.51fails (returns a 404 error when downloading) when the index has not yet been populated through other means. The crux of the issue is that thePackageIdinterner was treating0.8.0+cargo-0.51and0.8.0the same. Due to a chain of events, the interner was getting populated with0.8.0first, and then from there on always returned0.8.0. The full version information is needed to construct the download URL, so it was failing.The reason the interner was getting populated with a version without the metadata is the following sequence of events:
PackageIdusing aVersionReqwhere the build metadata has been removed (because version reqs don't have build metadata).PackageIdvalues created when parsing the index JSON files are now missing the build metadata because the interner is returning the wrong entries.PackageIdmissing the build metadata.I only changed
PackageIdInnerto pay attention to the build metadata. This seems a bit fragile, as perhapsPackageIdshould also pay attention to it. However, I don't really want to do an audit of every use ofPackageId, and offhand I can't think of other situations where it would matter.Closes #9410