Fix cargo install
with a semver metadata version.
#9467
Merged
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.51
fails (returns a 404 error when downloading) when the index has not yet been populated through other means. The crux of the issue is that thePackageId
interner was treating0.8.0 cargo-0.51
and0.8.0
the same. Due to a chain of events, the interner was getting populated with0.8.0
first, 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:
PackageId
using aVersionReq
where the build metadata has been removed (because version reqs don't have build metadata).PackageId
values created when parsing the index JSON files are now missing the build metadata because the interner is returning the wrong entries.PackageId
missing the build metadata.I only changed
PackageIdInner
to pay attention to the build metadata. This seems a bit fragile, as perhapsPackageId
should 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