Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #9467 - ehuss:install-metadata, r=alexcrichton
Fix `cargo install` with a semver metadata version. 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 the `PackageId` interner was treating `0.8.0+cargo-0.51` and `0.8.0` the same. Due to a chain of events, the interner was getting populated with `0.8.0` first, and then from there on always returned `0.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: 1. There is [this "fast path" code path](https://github.com/rust-lang/cargo/blob/d1baf0d81d0e4f91881de8e544c71fb49f623047/src/cargo/ops/cargo_install.rs#L570) which checks if a version of a package is already installed *before updating the index*. 2. Since the index doesn't exist yet, the resolver query returns zero entries (because the Registry Source is empty) [here](https://github.com/rust-lang/cargo/blob/d1baf0d81d0e4f91881de8e544c71fb49f623047/src/cargo/ops/common_for_install_and_uninstall.rs#L546-L550). 3. That code checks if the package has been yanked (because it can't tell the difference between "yanked" and "index not downloaded, yet"). 4. It constructs a `PackageId` using a `VersionReq` where the build metadata has been removed (because version reqs don't have build metadata). 5. When the real install continues (the error here is ignored for the purpose of this fast-path check if it is already installed), it downloads the index. However, the `PackageId` values created when parsing the index JSON files are now missing the build metadata because the interner is returning the wrong entries. 6. When the download starts, the URL is built from the `PackageId` missing the build metadata. I only changed `PackageIdInner` to pay attention to the build metadata. This seems a bit fragile, as perhaps `PackageId` should also pay attention to it. However, I don't really want to do an audit of every use of `PackageId`, and offhand I can't think of other situations where it would matter. Closes #9410
- Loading branch information