Add report if cargo fix --edition changes features.

[ehuss]

This adds a small report if using cargo fix --edition to transition from 2018 to 2021 to determine if the new resolver will result in different features.

There is a gauntlet of checks that must pass before it even tries to show the differences:

• If the resolver is already specified, skip.
• If in a virtual workspace, skip (no way to specify global edition).
• If not migrating the root package, skip. The edition only changes the resolver in the root package.
• If not migrating all targets, skip. It's uncertain if the user intends to set the package edition or not.

Closes #9048

[rust-highfive]

r? @alexcrichton

(rust-highfive has picked a reviewer for you, use r? to override)

[ehuss]

Overall I'm not too happy with this. The code seems a little awkward, though I can't say specifically why.

I am a little concerned that it is unreliable. Another concern is that the new resolver depends on many factors (the target, the --features flags used, and whether or not dev-dependencies are used). This report only captures a small snapshot of that (whatever settings the user provided to cargo fix).

Also, this doesn't actually run the final verification step with the new resolver. That will require significant changes to cargo fix, which I'm not sure how feasible that is.

I wanted to open this up for discussion to see if this is the direction we should go.

[alexcrichton]

This looks good to me, personally. Given the context of this, migrating between editions, I'd expect the code to be lossy, a bit odd, and possibly very specific to some situations. Also I would not expect 100% correctness guarantees from this code (just no false positive warnings).

I view the cargo fix --edition warnings as "best effort" where we do what we can for the 90% use case in theory, but there's likely to always be something that slips through the cracks or just isn't worth detecting and warning about.

The only thing I found surprising here was the check for --all-targets, was that necessary to reduce the warnings emitted?

[alexcrichton]

Drive-by comment not related to your PR, but this seems like it's ripe for a opts.copmile_opts.requested_features() method

[ehuss]

The only thing I found surprising here was the check for --all-targets, was that necessary to reduce the warnings emitted?

My thinking was that if you run cargo fix --edition --bin foo to incrementally migrate a package, you're intending to set edition on the bin target. I can probably remove that check, since I think that is a highly unlikely use case, and probably doesn't hurt to report differences.

[alexcrichton]

Want to go ahead and land this? We can presumably in the near-ish future try testing out cargo fix --edition for existing projects to see how it goes?

[ehuss]

Yea, I think it's ok to go. It can always be tweaked or removed. Hopefully we'll get enough people to test it before 2021 is stable. I'll assume that was an approval.

@bors r=alexcrichton

[bors]

📌 Commit 6c69e9d has been approved by alexcrichton

[bors]

⌛ Testing commit 6c69e9d with merge 90691f2...

[bors]

☀️ Test successful - checks-actions
Approved by: alexcrichton
Pushing 90691f2 to master...