-
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
Introduction of namespaced features (see #1286) #5300
Conversation
Thanks! I'm have a bit of a hard time following this though, mind adding some comments on the various Additionally, to recap, the idea here is that packages with this flag only activate optional dependencies through |
fe285e1
to
9dca40d
Compare
@alexcrichton I've added a whole bunch of comments. To recap: the idea here is that features live in a separate namespace from dependencies. As such, when specifying dependencies in a feature value list (in the features table), you have to prefix dependencies with Hope that makes sense. |
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.
Ok thanks so much for the comments, they're definitely quite helpful! I think this is definitely the right direction to go in, and with some tests this is likely good to go!
src/cargo/core/summary.rs
Outdated
dep | ||
), | ||
(&CrateFeature(_, _), Some(_)) | (&Feature(_), _) => {} | ||
(&CrateFeature(_, _), _, _) => {} |
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 explicitly list (&CrateFeature(_, _), true, _)
for exhaustiveness?
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.
Fixed.
☔ The latest upstream changes (presumably #5374) made this pull request unmergeable. Please resolve the merge conflicts. |
8c4caa5
to
8dc1761
Compare
Added a number of test cases that also did a good job flushing a number of logic issues out of the implementation. What is required in terms of documentation? One thing to consider: should |
Great, thanks! Mind adding documentation to I think we've still got some more design work to do on this before enabling it by default. Features enabled in 2018 must be warned against if they're incompatible with the previous edition for one thing, and we've also got the registry to worry about as we'll need to communicate this information to the registry and older versions of Cargo as well (as features affect dependency resolution). It's fine to punt those questions to later, though, as this is primarily just a new nightly feature that's "in the works" |
} | ||
values.push(val); | ||
} | ||
|
||
if !dependency_found { |
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 keep having a tough time following this dependency_found
logic, but is there a reason it needs to span across the match
statement above? Could this error be moved up before the match
?
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 added a whole bunch of comments, does that help? It spans across the for-loop (which includes the match) as a performance optimization: this way, we don't have to loop over the feature values twice. That's entirely premature (in the sense of not having done any performance measurements), so if the comments don't help enough, I could instead rewrite to check the values
list after the loop.
☔ The latest upstream changes (presumably #5335) made this pull request unmergeable. Please resolve the merge conflicts. |
8dc1761
to
2483ac6
Compare
I've rebased on latest master and added some documentation to the unstable section. |
@@ -763,6 +764,7 @@ impl TomlManifest { | |||
deps, | |||
me.features.clone().unwrap_or_else(BTreeMap::new), | |||
project.links.clone(), | |||
project.namespaced_features.unwrap_or(false), |
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.
Ah I just remembered, can this be gated behind a feature as well? (setting this key at all)
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.
Sure - not sure what kind of gate you had in mind?
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.
Oh something like cargo-features = ["namespaced-features"]
in Cargo.toml
, you can see some other examples of this via src/cargo/core/features.rs
I think
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.
@alexcrichton in that case, do we still need the separate namespaced-features
in the manifest? It seems like those would basically be duplicate values.
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.
For now yeah we'll want that (the Cargo feature basically unlocks the namespaced-features
config value).
Long term we may not have both but for the near-term I think we'll want that.
Ok thanks for the new comments, they look great! I think this is good to go with a feature gate and fixed tests! |
2483ac6
to
3719d31
Compare
Huh, those test failures got introduced by merging a conflict wrong. Fixed now, and rebased on current master. Just let me know what kind of feature gate you want and this can (finally!) be merged. |
☔ The latest upstream changes (presumably #5384) made this pull request unmergeable. Please resolve the merge conflicts. |
For now, all Summaries from a registry have it set to false.
…t-lang#1286) Here's an attempt at a table to cover the different cases: Feature Old (must be in features table) Continue Namespaced (might be stray value) In features table: Check that Crate dependency is in the list -> Non-optional dependency: Bail [PREVIOUSLY: bailed for non-optional dependency] -> Optional dependency: Insert feature of this name -> Else: Bail [PREVIOUSLY: bailed for unknown dependency or feature] Crate Old (might be stray value) Non-optional dependency: Bail No dependency found: Bail Namespaced Non-optional dependency: Bail No dependency found: Bail CrateFeature Old No dependency found: Bail Namespaced No dependency found: Bail
3719d31
to
dad55a3
Compare
Rebased on master and added the feature gate. Hope we can merge this now! |
Hm looks like CI may be failing? |
dad55a3
to
0b6f420
Compare
Don't know how I managed to break that -- I had at least some tests passing before. Anyway, it works now. |
@bors: r+ |
📌 Commit 0b6f420 has been approved by |
☀️ Test successful - status-appveyor, status-travis |
This fixes an accidental bug introduced in rust-lang#5300 by ensuring a local map keeps track of the fact that there can be multiple dependencies for one name Closes rust-lang#5453
I think this basically covers all of the plans from #1286, although it still needs a bunch of tests and documentation updates. Submitting this PR to get some early feedback on the direction.