Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix cargo update with unused patch. #8243

Merged
merged 1 commit into from
May 15, 2020

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented May 14, 2020

If you end up with an unused patch in Cargo.lock, then you try to update the patch to a version that does not match the original unused patch, and run cargo update, Cargo refuses to update it with the error "patch for bar in https://github.com/rust-lang/crates.io-index did not resolve to any crates". At this point, Cargo seems to be permanently stuck with no way to update it (unless you manually edit Cargo.lock).

The solution here is to add the unused patches to the "to_avoid" list, so that cargo update is allowed to update them.

I am uncertain if this is the best way to fix it, but seems to match my intuition of how cargo update is implemented.

@rust-highfive
Copy link

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 14, 2020
@ehuss
Copy link
Contributor Author

ehuss commented May 14, 2020

Note: The error points to #4678. It may be possible that some of the reports in that issue are due to this, though it is unclear.

@alexcrichton
Copy link
Member

@bors: r+

Nah this makes sense to me, this mirrors where other packages are ignored but unused patches aren't part of iteration so it makes sense to include them there to.

#4678 is a super old issue at this point and I still run into it every now and then, so I'm not sure if it fixes it. If I don't see it for awhile seems worthwhile to close it though!

@bors
Copy link
Contributor

bors commented May 15, 2020

📌 Commit 501e580 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 15, 2020
@bors
Copy link
Contributor

bors commented May 15, 2020

⌛ Testing commit 501e580 with merge 13bded9...

@bors
Copy link
Contributor

bors commented May 15, 2020

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing 13bded9 to master...

@bors bors merged commit 13bded9 into rust-lang:master May 15, 2020
@ehuss
Copy link
Contributor Author

ehuss commented May 15, 2020

I think the error message still shows up if you run cargo build at this line instead of running cargo update.

I probably should have addressed that as well, but I was a little unclear what scenarios hit that error. I'll try to follow up with another PR to try to improve the error message.

bors added a commit to rust-lang-ci/rust that referenced this pull request May 20, 2020
Update cargo

9 commits in cb06cb2696df2567ce06d1a39b1b40612a29f853..500b2bd01c958f5a33b6aa3f080bea015877b83c
2020-05-08 21:57:44 +0000 to 2020-05-18 17:12:54 +0000
- Handle LTO with an rlib/cdylib crate type (rust-lang/cargo#8254)
- Gracefully handle errors during a build. (rust-lang/cargo#8247)
- Update `im-rc` to 15.0.0 (rust-lang/cargo#8255)
- Fix `cargo update` with unused patch. (rust-lang/cargo#8243)
- Rephrased error message for disallowed sections in virtual workspace (rust-lang/cargo#8200)
- Ignore broken console output in some situations. (rust-lang/cargo#8236)
- Expand error message to explain that a string was found (rust-lang/cargo#8235)
- Add context to some fs errors. (rust-lang/cargo#8232)
- Move SipHasher to an isolated module. (rust-lang/cargo#8233)
bors added a commit that referenced this pull request May 21, 2020
Provide better error messages for a bad `patch`.

This attempts to provide more user-friendly error messages for some situations with a bad `patch`.  This is a follow-up to #8243.

I think this more or less covers all the issues from #4678.  I imagine there are other corner cases, but those will need to wait for another day. The main one I can think of is when the patch location is missing required features.  Today you get a "blah was not used in the crate graph." warning, with some suggestions added in #6470, but it doesn't actually check if there is a feature mismatch.

Closes #4678
@jdm
Copy link

jdm commented May 21, 2020

Thanks for fixing this!

@ehuss ehuss added this to the 1.45.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants