Unify weak and namespaced features.#9574
Conversation
|
(rust-highfive has picked a reviewer for you, use r? to override) |
|
So if I understand this correctly, you never need the dep prefix on feature dependencies because using a feature implies that the part before the slash is a dependency? |
|
Yea, that's the idea. |
|
Sounds good then, nice simplification! |
|
👍 @rfcbot fcp merge |
|
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
@bors: r+ |
|
📌 Commit 9034e48 has been approved by |
|
☀️ Test successful - checks-actions |
Update cargo This also updates `opener` used in bootstrap (to try to keep dependencies unified). 18 commits in 44456677b5d1d82fe981c955dc5c67734b31f340..9233aa06c801801cff75df65df718d70905a235e 2021-06-12 18:00:01 +0000 to 2021-06-22 21:32:55 +0000 - Detect incorrectly named cargo.toml (rust-lang/cargo#9607) - Unify weak and namespaced features. (rust-lang/cargo#9574) - Change `rustc-cdylib-link-arg` error to a warning. (rust-lang/cargo#9563) - Updates to future-incompatible reporting. (rust-lang/cargo#9606) - Add a compatibility notice for diesel and the new resolver. (rust-lang/cargo#9602) - Don't allow config env to modify vars set by cargo (rust-lang/cargo#9579) - Disambiguate is_symlink. (rust-lang/cargo#9604) - Update opener requirement from 0.4 to 0.5 (rust-lang/cargo#9583) - Avoid quadratic complexity when splitting output into lines (rust-lang/cargo#9586) - Bump to 0.56.0, update changelog (rust-lang/cargo#9597) - Fix dep-info files including non-local build script paths. (rust-lang/cargo#9596) - Relax doc collision error. (rust-lang/cargo#9595) - Handle "jobs = 0" case in cargo config files (rust-lang/cargo#9584) - Enhancements to testsuite error output. (rust-lang/cargo#9589) - Fix typo (rust-lang/cargo#9590) - Enable support for fix --edition for 2021. (rust-lang/cargo#9588) - Add more details for installing git repository errors (rust-lang/cargo#9582) - More information for links conflicting (rust-lang/cargo#9568)
Provide a better error message when mixing dep: with / Features of the form `dep:foo/feature` aren't accepted as valid syntax. This generated a somewhat confusing error message of: ``` feature `f1` includes `dep:bar/bar-feat`, but `dep:bar` is not a dependency ``` This PR adds a more targeted error message that provides some suggestions on how to fix it. There is more context in #9574 as to why the syntax is the way it is.
Fix dep/feat syntax with hidden implicit optional dependencies This fixes an issue with `dep/feat` syntax in the `[features]` table where it wouldn't work if the optional dependency had its implicit feature removed via the `dep:` syntax. The problem is that both resolvers were expecting that `dep/feat` would be able to activate a feature named "dep". But if that implicit feature wasn't created, then it would fail with an error. This was just an oversight (which probably happened in #9574). Fixes #10788
This unifies weak and namespaced features in order to simplify the syntax and semantics. Previously there were four different ways to specify the feature of a dependency:
package-name/feature-name— Enables featurepackage-nameon self and enablesfeature-nameon the dependency. (Today's behavior.)package-name?/feature-name— Only enablesfeature-nameon the given package if it that package is enabled and will also activates a feature namedpackage-name(which must be defined implicitly or explicitly).dep:package-name/feature-name— Enables dependencypackage-name, and enablesfeature-nameon that dependency. This does NOT enable a feature named "package-name".dep:package-name?/feature-name— Only enablesfeature-nameon the given package if it that package is enabled. This does NOT enable a feature named "package-name".This changes it so there are only two:
package-name/feature-name— Today's behavior.package-name?/feature-name— Only enablesfeature-nameon the given package if it that package is enabled. This does NOT enable a feature named "package-name" (the same behavior asdep:package-name?/feature-nameabove).This is a fairly subtle change, and in most cases probably won't be noticed. However, it simplifies things which helps with writing documentation and explaining how it works.