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

Introduction of namespaced features (see #1286) #5300

Merged
merged 8 commits into from
Apr 30, 2018

Conversation

djc
Copy link
Contributor

@djc djc commented Apr 5, 2018

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.

@alexcrichton
Copy link
Member

Thanks! I'm have a bit of a hard time following this though, mind adding some comments on the various bail! statements in the updated feature resolution loop?

Additionally, to recap, the idea here is that packages with this flag only activate optional dependencies through crate:foo, right?

@djc
Copy link
Contributor Author

djc commented Apr 16, 2018

@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 crate:. However, even after this PR, you do not have to specify a feature explicitly if you just have an optional dependency: for optional dependencies where no feature is explicitly defined, an implicit feature will be created -- this should help avoid boilerplate. Then again, if you do specify a feature of the same name as an optional dependency, it must include the crate:feature dependency.

Hope that makes sense.

Copy link
Member

@alexcrichton alexcrichton left a 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!

dep
),
(&CrateFeature(_, _), Some(_)) | (&Feature(_), _) => {}
(&CrateFeature(_, _), _, _) => {}
Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@bors
Copy link
Collaborator

bors commented Apr 17, 2018

☔ The latest upstream changes (presumably #5374) made this pull request unmergeable. Please resolve the merge conflicts.

@djc djc force-pushed the namespaced-features branch 3 times, most recently from 8c4caa5 to 8dc1761 Compare April 18, 2018 11:43
@djc djc changed the title [WIP] Introduction of namespaced features (see #1286) Introduction of namespaced features (see #1286) Apr 18, 2018
@djc
Copy link
Contributor Author

djc commented Apr 18, 2018

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 namespaced-features default to true for Edition2018?

@alexcrichton
Copy link
Member

Great, thanks! Mind adding documentation to unstable.md in the src/doc directory about this feature?

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 {
Copy link
Member

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?

Copy link
Contributor Author

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.

@bors
Copy link
Collaborator

bors commented Apr 21, 2018

☔ The latest upstream changes (presumably #5335) made this pull request unmergeable. Please resolve the merge conflicts.

@djc
Copy link
Contributor Author

djc commented Apr 23, 2018

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),
Copy link
Member

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)

Copy link
Contributor Author

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?

Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

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.

@alexcrichton
Copy link
Member

Ok thanks for the new comments, they look great! I think this is good to go with a feature gate and fixed tests!

@djc
Copy link
Contributor Author

djc commented Apr 25, 2018

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.

@bors
Copy link
Collaborator

bors commented Apr 27, 2018

☔ The latest upstream changes (presumably #5384) made this pull request unmergeable. Please resolve the merge conflicts.

djc added 7 commits April 28, 2018 13:41
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
@djc
Copy link
Contributor Author

djc commented Apr 30, 2018

Rebased on master and added the feature gate. Hope we can merge this now!

@alexcrichton
Copy link
Member

Hm looks like CI may be failing?

@djc
Copy link
Contributor Author

djc commented Apr 30, 2018

Don't know how I managed to break that -- I had at least some tests passing before. Anyway, it works now.

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Collaborator

bors commented Apr 30, 2018

📌 Commit 0b6f420 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Apr 30, 2018

⌛ Testing commit 0b6f420 with merge 4963d88...

bors added a commit that referenced this pull request Apr 30, 2018
Introduction of namespaced features (see #1286)

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.
@bors
Copy link
Collaborator

bors commented Apr 30, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 4963d88 to master...

@bors bors merged commit 0b6f420 into rust-lang:master Apr 30, 2018
alexcrichton added a commit to alexcrichton/cargo that referenced this pull request May 2, 2018
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
bors added a commit that referenced this pull request May 2, 2018
Fix optional dependencies and required dev-deps

This fixes an accidental bug introduced in #5300 by ensuring a local map keeps
track of the fact that there can be multiple dependencies for one name

Closes #5453
@djc djc mentioned this pull request Mar 27, 2020
1 task
@ehuss ehuss added this to the 1.27.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment