-
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
Using dep:
syntax in Cargo.toml makes it impossible to enable features for dependencies unless you also have a feature by that name
#10788
Comments
Thanks for the report! I'm not sure how we missed that. |
Interesting, I was confused because I thought I was using this setup in a crate of mine just fine; but it looks like if you use |
Thanks for the workaround :) |
As this doesn't seem to be very active, I'll try it and see what happens :) |
Cargo bug: rust-lang/cargo#10788 Caused meli to not be able to be installed with 1.70.0 cargo. This commit expresses the static dependencies differently to allow both 1.70.0 and later versions understand the optional dependency feature activation. Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
We don't need it. With the feature enabled, doing dependency resolution with Cargo versions before 1.71 fails due to rust-lang/cargo#10788 . ``` the package `samply` depends on `opener`, with features: `dbus` but `opener` does not have these features. ```
See rust-lang/cargo#10788 for the full issue. When enabling a feature of a dependency, the syntax `tokio/rt` implicitly required a feature `tokio` to exist in 1.70 of cargo. By 1.77 this has been fixed. To work around this, we can use "weak feature dependencies" like `tokio?/rt` which enables the `rt` feature of tokio only if tokio is itself an enabled dependency. Also adding `dep:tokio` to the list of dependencies ensures that this is always true. When the MSRV is upgraded again, we can probably remove the weak `?` and the `dep:tokio` in these cases.
As described in Cargo Issue 10788, until Rust 1.71 there were cases where the dependency/feature syntax would not work correctly when used in combination with the dep:dependency syntax. Workarounds include adding an explicit feature dependency = ["dep:dependency"] but in many (most?) cases it is enough to only enable the dependency feature if the dependency is already enabled, via the dependency?/feature syntax. For context, here are some workarounds employed by others: - mstange/samply@89456d4 - alexrudy/tonic@f386954 - jwodder/confab@6f0e2fc
As described in Cargo Issue 10788, until Rust 1.71 there were cases where the dependency/feature syntax would not work correctly when used in combination with the dep:dependency syntax. Workarounds include adding an explicit feature dependency = ["dep:dependency"] but in many (most?) cases it is enough to only enable the dependency feature if the dependency is already enabled, via the dependency?/feature syntax. For context, here are some workarounds employed by others: - mstange/samply@89456d4 - alexrudy/tonic@f386954 - jwodder/confab@6f0e2fc
See rust-lang/cargo#10788 for the full issue. When enabling a feature of a dependency, the syntax `tokio/rt` implicitly required a feature `tokio` to exist in 1.70 of cargo. By 1.77 this has been fixed. To work around this, we can use "weak feature dependencies" like `tokio?/rt` which enables the `rt` feature of tokio only if tokio is itself an enabled dependency. Also adding `dep:tokio` to the list of dependencies ensures that this is always true. When the MSRV is upgraded again, we can probably remove the weak `?` and the `dep:tokio` in these cases.
See rust-lang/cargo#10788 for the full issue. When enabling a feature of a dependency, the syntax `tokio/rt` implicitly required a feature `tokio` to exist in 1.70 of cargo. By 1.77 this has been fixed. To work around this, we can use "weak feature dependencies" like `tokio?/rt` which enables the `rt` feature of tokio only if tokio is itself an enabled dependency. Also adding `dep:tokio` to the list of dependencies ensures that this is always true. When the MSRV is upgraded again, we can probably remove the weak `?` and the `dep:tokio` in these cases.
See rust-lang/cargo#10788 for the full issue. When enabling a feature of a dependency, the syntax `tokio/rt` implicitly required a feature `tokio` to exist in 1.70 of cargo. By 1.77 this has been fixed. To work around this, we can use "weak feature dependencies" like `tokio?/rt` which enables the `rt` feature of tokio only if tokio is itself an enabled dependency. Also adding `dep:tokio` to the list of dependencies ensures that this is always true. When the MSRV is upgraded again, we can probably remove the weak `?` and the `dep:tokio` in these cases.
It was throwing this error rust-lang/cargo#10788
Any crate with this Cargo.toml, or any one like it:
fails to compile because of the
allsorts/flate2_rust
, even though it shouldn't (allsorts
is a dependency, not a feature name).Adding an
allsorts
feature, even a completely empty one, fixes the error:so this is probably a misbehaving lint. I don't want an extra
allsorts
feature (in my real crate,font
is more than justallsorts
, and enablingallsorts
on its own makes 0 sense).If this lint exists for encapsulation purposes, I would like to be able to do
dep:allsorts/flate2_rust
at least, if there is no outer-facingallsorts
feature (although I'd add one in that case so that downstream crates can configure which flate2 backend they want).Active toolchain:
I have made a minimum effort to search for duplicate issues, but "dep cargo feature" is such a generic search term that it gives thousands of results.
The text was updated successfully, but these errors were encountered: