Tracking Issue for remove-implicit-feature RFC 3491

[ehuss]

Summary

RFC: #3491

Implementation:

• feat: Add a basic linting system #13621
• Unused dependencies cleanup #13778
• fix(fix): Address problems with implicit -> explicit feature migration #14018
• fix: Ensure dep/feature activates the dependency on 2024  #14221
  • Revert "fix: Ensure dep/feature activates the dependency on 2024" #14295
• fix: Remove implicit feature removal #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

• Bad error message when a strong dep features's depedency is an unused optional dependency #14016
• Have cargo add --optional <dep> create a <dep> = "dep:<dep> feature #11010
• Activation of features of non-optional dependencies breaks manifest for 2024 edition #14283

Unresolved

• Suggested adding dep:foo to the foo feature if it exists for unused optional dependencies #14017

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.

[ehuss]

@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.

[epage]

@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.

[epage]

@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

[linyihai]

Option 1: We strip unused optional dependencies before generating a Summary / before publish

So this RFC implemetation can also fixed or mitgiate #10801 ?

[epage]

No, that is unrelated to what was being proposed to be stripped.

[ehuss]

The cargo team has decided to drop this from the 2024 edition. There are some implementation issues, and we feel that there is just too much risk trying to resolve it at such a late date. We will update here when we have decided what to do in the future.

[epage]

#14630 removes the removal of implicit features from Edition 2024.

#14016 has a note explaining what led to this problem and some potential solutions.