'cargo update -p foo' fails with [patch]’ed depenedency

[SimonSapin]

servo/rust-cssparser#171 makes a number of changes to the cssparser crate, including changing its version number from 0.17.0 to 0.18.0. That PR has not landed yet, 0.18.0 is not on crates.io yet. I want to test it in Servo beforehand. I already had a Servo branch with [replace] (and a separate cssparser branch with a silly commit that reverses the version number change…) Now that rust-lang/rust#43319 has landed, I tried [patch] instead.

Starting from Servo master, I changed cssparser = "0.17" to cssparser = "0.18" in a dozen Cargo.toml files, added the lines below to the workspace’s Cargo.toml, and cherry-picked the commits updating the code for API changes.

[patch.crates-io]
cssparser = {git = "https://github.com/servo/rust-cssparser", rev = "token-cache"}

At this point, with [replace], I’d usually need to run cargo update -p cssparser to get Cargo.lock in a state consistent with toml files. This fails:

% cargo update -p cssparser
    Updating git repository `https://github.com/servo/rust-cssparser`
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: no matching version `^0.18` found for package `cssparser` (required by `style_traits`)
location searched: registry https://github.com/rust-lang/crates.io-index
versions found: 0.17.0, 0.16.1, 0.16.0, ...

Though cargo build succeeds, so it looks like [patch] is working as intended. It’s only the update sub-command that apparently still needs to learn about it.

[alexcrichton]

Are you sure you were using the right version of Cargo? It looks like the code paths here should do the right thing, although I haven't super thoroughly checked.

As a side note, I find these sorts of reports much more approachable if quotes like "with a silly commit ..." are all left out, we all just want to help everyone else get work done!

[SimonSapin]

Sorry about the unnecessary "silly commit" part. Thank you for your work on [patch] which does fix this.

I was using cargo 0.21.0-nightly (ffab519 2017-07-18), built on Rust CI, which was updated in rust-lang/rust#43319.

[SimonSapin]

I tried to reproduce this with a minimal test case and didn’t get any error. So you’re right, I might have used cargo instead of ./mach crago and forgot that that was a different version that didn’t have [patch] support yet.

[alexcrichton]

Ok, lemme know if it keeps coming up though! I'm not 100% sure this isn't a bug yet.

[SimonSapin]

FWIW, here is the script I used to try to reproduce:

cargo new matches
sed -i 's/0.1.0/999.0.0/' matches/Cargo.toml
cat matches/Cargo.toml

cargo new foo
echo 'matches = "999.0.0"' >> foo/Cargo.toml
echo '' >> foo/Cargo.toml
echo '[patch.crates-io]' >> foo/Cargo.toml
echo 'matches = {path = "../matches"}' >> foo/Cargo.toml
cat foo/Cargo.toml

cargo +nightly build --manifest-path foo/Cargo.toml  # Succeeds
cargo +nightly update --manifest-path foo/Cargo.toml -p matches  # I expected this to fail, but it succeeded

rm -r matches foo