cargo
cargo copied to clipboard
rust-lang
Tracking Issue for remove-implicit-feature RFC 3491
Summary
RFC: #3491
Implementation:
- https://github.com/rust-lang/cargo/pull/13621
- https://github.com/rust-lang/cargo/pull/13778
- https://github.com/rust-lang/cargo/pull/14018
- https://github.com/rust-lang/cargo/pull/14221
- https://github.com/rust-lang/cargo/pull/14295
- https://github.com/rust-lang/cargo/pull/14630
Documentation: TODO Closes: #9088, #10125
Removes the implicit feature created for optional dependencies, requiring them to be explicitly stated in the [features] table with dep:foo syntax.
[!NOTE] This has been deferred out of the 2024 edition. More updates will come in the future.
Issues
- https://github.com/rust-lang/cargo/issues/14016
- https://github.com/rust-lang/cargo/issues/11010
- https://github.com/rust-lang/cargo/issues/14283
Future Extensions
No response
About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
@epage Do you want to take on implementation of this, or know someone who will? Or, if not, do you want to write mentoring instructions? I can probably do that if you don't.
@Muscraft is taking this on atm as his test case for #12235. We should pick a time to re-evaluate and, if that isn't ready in time, we pivot and hard code all of this where it is needed.
@Muscraft and I have been talking about how to implement this.
Instead of erroring in the 2024 Edition that an implicit feature was created, we are looking at treating it as an "unused optional dependency" warning. However, to truly be unused, no implicit feature should be created.
So how do we avoid that implicit feature?
Option 1: We strip unused optional dependencies before generating a Summary / before publish
This will "just work". All past and future versions of Cargo will not be able to access an implicit feature.
This would be an impediment to running other lints on unused optional dependencies because we'd be throwing out the information we'd use for linting.
This means that unused optional dependencies would not affect dependency resolution and not be included in Cargo.lock, like workspace.dependencies and unlike unused transitive dependencies from weak features (#10801).
Option 2: We include the edition in the summary
We then use edition to decide whether optional dependencies should have implicit features created.
Maybe other future work could benefit from this?
This would be quite a bit of work, requiring crates.io changes and communicating out changes required for third-party registries to support Edition 2024. But we only have 2 weeks left and coordinating across teams within that time span might be difficult.
Without a index format bump or required MSRV, old cargo will ignore Edition, allow these, and create implicit featurese
Option 3: We punt and have this warning be an error
Nuff said
Option 4: When generating the Summary / published Cargo.toml, we create foo = ["dep:foo"] features for pre-2024 Edition
The problem with this is it would require a server backfill to function properly which in a way would be a breaking change for third-party registries
Option 1: We strip unused optional dependencies before generating a Summary / before publish
So this RFC implemetation can also fixed or mitgiate #10801 ?
