`cargo fix --edition` gives an unstable error

[jyn514]

Problem
I want to convert a crate in a workspace from 2015 to 2018 edition. Because another crate in the workspace already uses 2018 edition, cargo tries to convert it to 2021 and gives an error that 2021 is still unstable.

$ cargo fix --edition
    Checking boring-sys v1.1.1 (/home/jnelson/src/boring/boring-sys)
    Checking boring v1.1.6 (/home/jnelson/src/boring/boring)
error: cannot migrate boring-sys/src/lib.rs to edition 2021
Edition 2021 is unstable and not allowed in this release, consider trying the nightly release channel.
   Migrating boring/src/lib.rs from 2015 edition to 2018
error: could not compile `boring-sys`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...

Steps

1. git clone https://github.com/cloudflare/boring/
2. cd boring
3. cargo fix --edition

Possible Solution(s)

Only try to migrate crates to the latest stable edition unless the user explicitly opts-in to upgrading to the unstable edition.

Notes

Output of cargo version:

cargo 1.54.0 (5ae8d74b3 2021-06-22)

[weihanglo]

Do we have any expected behavior for opts-in to upgrading to the unstable edition? Like by running cargo +nightly fix it implies upgrading to next unstable edition. Though I am not too fond of my solution here because it's too implicit and inconsistent between stable/nightly.

[weihanglo]

The alternative solution may look like this:

• --edition <value> starts accepting values such as 2015, 2018 and 2021.
• When using --edition without a value, simply migrate to the next stable edition.
  • For workspace, all members migrate to their own next edition accordingly.
• When using --edition with a value, migrate to the specified edition.
  • For workspace, all members migrate to the same specified edition.
  • cargo rejects any --edition <value> that tries to downgrade to a previous edition.

Hope it's not too overkill.

[ehuss]

I think we would prefer to avoid passing specific values to the edition flag, because it can only supporting going to the "next" edition, and I think that would introduce some unwanted complexity. Generally in this case if there are mixed editions in a workspace, it is encouraged to use -p flags to narrow which packages are selected.

I think it would be fine to change the error to a warning, and just ignore the packages that are already on the latest, stable version. That logic would go around here and I think would involve just emitting a Message::EditionAlreadyEnabled instead of an error. It might be nice for the warning to give a hint about using the nightly channel if the next edition is unstable.

Unfortunately, it is probably a little late for that, since 2021 is likely to be stabilized soon, but I think fixing that case is still worthwhile.

[weihanglo]

@rustbot claim