Test for bad path overrides with summaries #3336
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bad path overrides are currently detected to issue warnings in cases where path overrides are not suitable and have exhibited buggy behavior in the past. Unfortunately though it looks like some false positives are being issued, causing unnecessary confusion about `paths` overrides. This commit fixes the detection of these "bad path overrides" by comparing `Summary` dependencies (what's written down in `Cargo.toml`) rather than comparing the `Cargo.toml` of the override with `Cargo.lock`. We're guaranteed that the package we're overridding has already been resolved into `Cargo.lock`, so we know that if the two `Cargo.toml` files are equivalent we'll continue with the same crate graph. I'm not actually entirely sure why I originally thought it'd be better to go through the `Cargo.lock` comparison route. Unfortunately that doesn't take into account optional deps which aren't in `Cargo.lock` but are in `Cargo.toml` of the override, causing the false positive. This method, however, simply ensures that the two dependency lists are the same. Closes rust-lang#3313
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ |
|
📌 Commit 772e1a1 has been approved by |
bors
added a commit
that referenced
this pull request
Dec 2, 2016
Test for bad path overrides with summaries Bad path overrides are currently detected to issue warnings in cases where path overrides are not suitable and have exhibited buggy behavior in the past. Unfortunately though it looks like some false positives are being issued, causing unnecessary confusion about `paths` overrides. This commit fixes the detection of these "bad path overrides" by comparing `Summary` dependencies (what's written down in `Cargo.toml`) rather than comparing the `Cargo.toml` of the override with `Cargo.lock`. We're guaranteed that the package we're overridding has already been resolved into `Cargo.lock`, so we know that if the two `Cargo.toml` files are equivalent we'll continue with the same crate graph. I'm not actually entirely sure why I originally thought it'd be better to go through the `Cargo.lock` comparison route. Unfortunately that doesn't take into account optional deps which aren't in `Cargo.lock` but are in `Cargo.toml` of the override, causing the false positive. This method, however, simply ensures that the two dependency lists are the same. Closes #3313
|
☀️ Test successful - status-appveyor, status-travis |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Bad path overrides are currently detected to issue warnings in cases where path
overrides are not suitable and have exhibited buggy behavior in the past.
Unfortunately though it looks like some false positives are being issued,
causing unnecessary confusion about
pathsoverrides.This commit fixes the detection of these "bad path overrides" by comparing
Summarydependencies (what's written down inCargo.toml) rather thancomparing the
Cargo.tomlof the override withCargo.lock. We're guaranteedthat the package we're overridding has already been resolved into
Cargo.lock,so we know that if the two
Cargo.tomlfiles are equivalent we'll continuewith the same crate graph.
I'm not actually entirely sure why I originally thought it'd be better to go
through the
Cargo.lockcomparison route. Unfortunately that doesn't take intoaccount optional deps which aren't in
Cargo.lockbut are inCargo.tomlofthe override, causing the false positive. This method, however, simply ensures
that the two dependency lists are the same.
Closes #3313