Due to problems we ran into with #14016, we're removing implicit
features from the 2024 edition to give ourselves more time to design it
as we should.
I could have added a new flag for this or made an EditionNext but I
decided to remove it in the hopes to avoid any path dependency in
solving this the next time.
This is for `cargo generate-lockfile` and when syncing the lockfile with
the manifest.
We still show it for `cargo update` because of `cargo update
--workspace`.
We hacked around this previously by filtering out the `num_pkgs==1` case
for single packages but this didn't help with workspaces.
Fixes#14283 by re-opening #14016 so we don't block people testing other
Edition 2024 changes.
This reverts commit 99fae9187ac0bae12a03585083169e34dc7a197d.
fix: improve message for inactive weak optional feature with edition2024 through unused dep collection
### What does this PR try to resolve?
Collect the unused dependencies to check whether a weak optional dependency had set. Then we can improve the message when weak optional dependency inactive.
Fixes https://github.com/rust-lang/cargo/issues/14015
### How should we test and review this PR?
One commit test added, one commit fixed and updated
### Additional information
Part of https://github.com/rust-lang/cargo/issues/14039
- migrate `tests/testsuite/lints/unused_optional_dependencies.rs` to snapshot
And rename `MissingField` to `MissingFieldError`
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
This is to help with #9930
Example changes:
```diff
-[LOCKING] 4 packages
+[LOCKING] 4 packages to latest version
-[LOCKING] 2 packages
+[LOCKING] 2 packages to latest Rust 1.60.0 compatible versions
-[LOCKING] 2 packages
+[LOCKING] 2 packages to earliest versions
```
Benefits
- The package count is of "added" packages and this makes that more
logically clear
- This gives users transparency into what is happening, especially with
- what rust-version is use
- the transition to this feature in the new edition
- whether the planned config was applied or not (as I don't want it to
require an MSRV bump)
- Will make it easier in tests to show what changed
- Provides more motiviation to show this message in `cargo update` and
`cargo install` (that will be explored in a follow up PR)
This does come at the cost of more verbose output but hopefully not too
verbose. This is why I left off other factors, like avoid-dev-deps.
