-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Only allow one of each links attribute in resolver #4978
Changes from 4 commits
78f3564
732d29d
1ee77e4
87d188f
3fb2981
58590ae
affddaa
4d2d444
50cd36a
ddccbca
e8ed405
70dada8
68a40ad
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -227,6 +227,7 @@ not have a custom build script | |
|
||
#[test] | ||
fn links_duplicates() { | ||
// this tests that the links_duplicates are caught at resolver time | ||
let p = project("foo") | ||
.file("Cargo.toml", r#" | ||
[project] | ||
|
@@ -256,20 +257,15 @@ fn links_duplicates() { | |
assert_that(p.cargo("build"), | ||
execs().with_status(101) | ||
.with_stderr("\ | ||
[ERROR] multiple packages link to native library `a`, but a native library can \ | ||
be linked only once | ||
|
||
package `foo v0.5.0 ([..])` | ||
links to native library `a` | ||
|
||
package `a-sys v0.5.0 ([..])` | ||
... which is depended on by `foo v0.5.0 ([..])` | ||
also links to native library `a` | ||
error: failed to select a version for `a-sys` (required by `foo`): | ||
all possible versions conflict with previously selected versions of `a-sys` | ||
possible versions to select: 0.5.0 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if we could perhaps tidy up the wording around this sort of error? I found this sort of hard to follow as there's a lot of mentions of versions and such. Maybe something like:
I do realize that most of this is fitting in the mold of the previous error messages, but perhaps we can just tidy up the wording around them? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will see what I can do. :-) One thing to keep in mind is that different versions of a-sys may have different errors we need to report. For example only some versions have the link attribute. So we may, at least in theory, have to coherently report on a link error with 'a-fork-sys' and a semver error with 'a-sys' from before it had a link attribute. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I'm not entirely sure what to do about "given all these errors present the most reasonable one". I'm ok punting on it for now though or otherwise maybe adding a heuristic to print errors where everything is at maximal versions or something like that |
||
")); | ||
} | ||
|
||
#[test] | ||
fn links_duplicates_deep_dependency() { | ||
// this tests that the links_duplicates are caught at resolver time | ||
let p = project("foo") | ||
.file("Cargo.toml", r#" | ||
[project] | ||
|
@@ -311,16 +307,9 @@ fn links_duplicates_deep_dependency() { | |
assert_that(p.cargo("build"), | ||
execs().with_status(101) | ||
.with_stderr("\ | ||
[ERROR] multiple packages link to native library `a`, but a native library can \ | ||
be linked only once | ||
|
||
package `foo v0.5.0 ([..])` | ||
links to native library `a` | ||
|
||
package `a-sys v0.5.0 ([..])` | ||
... which is depended on by `a v0.5.0 ([..])` | ||
... which is depended on by `foo v0.5.0 ([..])` | ||
also links to native library `a` | ||
error: failed to select a version for `a-sys` (required by `a`): | ||
all possible versions conflict with previously selected versions of `a-sys` | ||
possible versions to select: 0.5.0 | ||
")); | ||
} | ||
|
||
|
@@ -2741,6 +2730,7 @@ fn deterministic_rustc_dependency_flags() { | |
|
||
#[test] | ||
fn links_duplicates_with_cycle() { | ||
// this tests that the links_duplicates are caught at resolver time | ||
let p = project("foo") | ||
.file("Cargo.toml", r#" | ||
[project] | ||
|
@@ -2783,17 +2773,9 @@ fn links_duplicates_with_cycle() { | |
assert_that(p.cargo("build"), | ||
execs().with_status(101) | ||
.with_stderr("\ | ||
[ERROR] multiple packages link to native library `a`, but a native library can \ | ||
be linked only once | ||
|
||
package `foo v0.5.0 ([..])` | ||
... which is depended on by `b v0.5.0 ([..])` | ||
links to native library `a` | ||
|
||
package `a v0.5.0 (file://[..])` | ||
... which is depended on by `foo v0.5.0 ([..])` | ||
... which is depended on by `b v0.5.0 ([..])` | ||
also links to native library `a` | ||
error: failed to select a version for `a` (required by `foo`): | ||
all possible versions conflict with previously selected versions of `a` | ||
possible versions to select: 0.5.0 | ||
")); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this assert that we're not replacing somethign that was already there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could make it
assert!(self.links.insert(link.to_owned()));
but I think this can get triggered if updating a lock file that already has multiple crates with the same links attribute. Is this acceptable? Is there some way to get better error messages?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm that would indeed be bad! Thinking through how this can happen I think we could trigger this if an older cargo created a lock file with a bunch of new crates (that all have
links
in the manifest) and then a newer cargo tries to use that lock file.In that case, sounds like we should skip the assert for now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Er well, but if we do actually run into that case the previous project surely couldn't build previously becuase it would have been caught later...
How about this, could we return an error from here to entirely abort resolution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I have that working now.