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

Using dep: syntax in Cargo.toml makes it impossible to enable features for dependencies unless you also have a feature by that name #10788

Closed
LoganDark opened this issue Jun 24, 2022 · 4 comments · Fixed by #12130
Labels
A-features Area: features — conditional compilation A-namespaced-features Area: namespaced-features C-bug Category: bug S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review

Comments

@LoganDark
Copy link

LoganDark commented Jun 24, 2022

Any crate with this Cargo.toml, or any one like it:

[package]
name = 'whatever'
version = '0.1.0'
edition = '2021'

[features]
default = ['font', 'allsorts/flate2_rust']
font = ['dep:allsorts']

[dependencies]
allsorts = { version = '~0.10.0', optional = true, default-features = false }

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:

[package]
name = 'whatever'
version = '0.1.0'
edition = '2021'

[features]
default = ['font', 'allsorts/flate2_rust']
font = ['dep:allsorts']
allsorts = []

[dependencies]
allsorts = { version = '~0.10.0', optional = true, default-features = false }

so this is probably a misbehaving lint. I don't want an extra allsorts feature (in my real crate, font is more than just allsorts, and enabling allsorts 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-facing allsorts feature (although I'd add one in that case so that downstream crates can configure which flate2 backend they want).

Active toolchain:

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.63.0-nightly (dc80ca78b 2022-06-21)

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.

@LoganDark LoganDark added the C-bug Category: bug label Jun 24, 2022
@ehuss ehuss transferred this issue from rust-lang/rust Jun 24, 2022
@ehuss
Copy link
Contributor

ehuss commented Jun 24, 2022

Thanks for the report! I'm not sure how we missed that.

@ehuss ehuss added A-features Area: features — conditional compilation A-namespaced-features Area: namespaced-features S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review labels Jun 24, 2022
@Nemo157
Copy link
Member

Nemo157 commented Jul 28, 2022

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 allsorts?/flate2_rust it works fine, and I happened to be using weak-features for all my namespaced crates.

@LoganDark
Copy link
Author

it looks like if you use allsorts?/flate2_rust it works fine

Thanks for the workaround :)

@blyxyas
Copy link
Member

blyxyas commented Apr 18, 2023

As this doesn't seem to be very active, I'll try it and see what happens :)
@rustbot claim

@blyxyas blyxyas removed their assignment Apr 22, 2023
@bors bors closed this as completed in e41605b May 13, 2023
epilys added a commit to meli/meli that referenced this issue Dec 10, 2023
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>
jwodder added a commit to jwodder/confab that referenced this issue Jan 9, 2024
mstange added a commit to mstange/samply that referenced this issue Apr 4, 2024
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.
```
alexrudy added a commit to alexrudy/tonic that referenced this issue Apr 13, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-features Area: features — conditional compilation A-namespaced-features Area: namespaced-features C-bug Category: bug S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants