Use of patch in Cargo.toml to override dependency requires .cargo/registry to be cleared when patch removed.

[johnoneil]

Problem

Got into a very confusing situation whereby I patched in a crate for local development and then removed the patch, and went several days with the patched version of the crate still present in my .cargo/registry.

I would think that when a patch statement is removed, the relevant registry entry should be removed and re-cached.

Our current workaround is to remove the entire Cargo cash via:

rm -fr ~/.cache/registry

Steps

1. Provide a patch statement in your Cargo.toml

[patch.crates-io]
crate = { path = "path/to/crate" }

2. Build and develop. You should now be using the patched version of the crate.

3. Remove the patch statement from your Cargo.toml

4. The bug should be present, in that you should still be building using the patched version of your crate when you no longer should.

5. A manual deletion of the Cargo registry should be necessary to correct this.

Possible Solution(s)

No response

Notes

No response

Version

No response

[ehuss]

Hm, that's strange. Can you provide more information about what made it appear that it was still using the patch? Can you provide a basic reproduction? For example, the following seems to work for me:

1. cargo new foo
2. cd foo
3. cargo add itoa
4. rm src/main.rs
5. echo 'fn main() { println!("{}", itoa::Buffer::new().format(100)); }' > src/main.rs
6. cargo run
   Displays: 100
7. git clone https://github.com/dtolnay/itoa.git
8. Add to Cargo.toml:

   [patch.crates-io]
   itoa.path = "itoa"

9. cargo run
   Still displays: 100
10. Edit itoa/src/lib.rs, replace the first digit of DEC_DIGITS_LUT to a 9.
11. cargo run
    Displays: 190
12. Edit Cargo.toml and remove the [patch.crates-io] table.
13. cargo run
    Displays: 100

[johnoneil]

Yeah I just don't have the time to push this right now. There could be any number of additional factors contributing to this, which I can't take the time to isolate:

• We're working in a workspace
• We have some additional (redundant) Cargo.lock files checked in
• We're doing cross compilation with additional rustup toolchains.

I did encounter this problem and it was pretty subtle and bothersome so I thought it worth noting. I'll bump this If I can recreate more exactly, but I can't contribute more currently. You can close if you like.

[weihanglo]

Thanks for the report. Going to close this for now due to inactivity. If you have time to investigate and provide a minimal reproduction, feel free to open a new issue :)

[ReactorScram]

Hey there, just had this happen to me

I patched sctp-proto 0.2.2 to use instant instead of std::time so it could build in wasm.
A couple days passed and later I'm not able to build main for our project because Cargo says I'm referring to instant on this line is actually referring to std::time and hasn't changed for months upstream: https://github.com/webrtc-rs/sctp-proto/blob/main/src/association/mod.rs#L43

I ran rm -rf ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sctp-proto-0.2.2/ and my cargo check -p command immediately passed after that.

Using cargo 1.79.0 (ffa9cf99a 2024-06-03)

We are also in a workspace but only have one Cargo.lock, and I never merged my wasm patch, so on our main, sctp-proto is not patched: https://github.com/firezone/firezone/blob/f00d32df14d100609799ba861d9e2ca06ca12e27/rust/Cargo.lock#L5432

We don't depend on sctp-proto directly, it's a transitive dependency from str0m which we did patch: https://github.com/firezone/firezone/blob/f00d32df14d100609799ba861d9e2ca06ca12e27/rust/Cargo.lock#L5922

Maybe the transitive dependency confused it. We do have cross-compiling set up for some crates, but in this case I was just running cargo check -p connlib-client-shared on my macOS host, and that crate should check on Linux, macOS, and Windows just fine. (Actually cargo check -p snownet would probably replicate this, since snownet is what depends on str0m, but I don't want to start this problem again right now on my system)

Would it help if I made a reproduction repo? With say, 2 different Rust projects and a Bash script with commented-out commands like this:

# pseudo-code
cd project_a # Unpatched
cargo check
cd ../project_b # Patched
cargo check # Triggers the bug
cd ../project_a
cargo check # Should replicate the bug
# Somewhat destructive, so commented-out
# m -rf ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sctp-proto-0.2.2/
# Bug is now un-triggered
cargo check

It would take a few hours so I don't want to start now but I could probably do it.

[weihanglo]

@ReactorScram thanks for the detailed write-up! It would be appreciated if you could share a minimal reproduction.

[ReactorScram]

I couldn't figure it out. It must be some strange combination of factors. Stuff from crates.io gets cached in ~/.cargo/registry/src, but patches from Git repos are cached in ~/.cargo/git/checkouts. I'm not sure how it got mixed up.

[weihanglo]

Would it be that like IDE tool messed this up? The checked out sources are not readonly #9455.

[ReactorScram]

Possibly. I may have had VS Code open while this was all happening, and it has rust-analyzer on