Fix #8571: A new source version and migration scheme

[odersky]

Unlike originally proposed in #8571, we now just use -source, the separate
-migration setting is gone. We replace it by having source versions for migrations.
So, right now, we have

3.0, 3.1, 3.0-migration and 3.1-migration.

A X-migration source level means that migration warnings and changes in preparation
for the X source level are enabled.

So, the scenarios in #8571 would map as follows:

• I want to cross compile between Scala 2 and Scala 3: not yet implemented, but it would be -source 2x3
• I want help with migration to Scala 3: -source 3.0-migration
• I want help with migration to the cross-compilable subset: not yet implemented, but it would be -source 2x3-migration
• I want to make sure my code is future-proof for 3.1: -source 3.1
• I want help making my code future-proof for 3.1: -source 3.1-migration
• My compiler's version is3.1, but I want to stick to the more lenient 3.0 version for the moment: -source 3.0.
• My compiler's version is 3.1, but I want to stick to the cross-compilable subset: not yet implemented, but it would be -source 2x3

[odersky]

Compared to the scheme I proposed in #8571, the upside of the PR is that we no longer have a -migration option that depends on context. The downside is that it's a bit more complicated for the
immediate use case, which is to go from 2 to 3: It's now -source 3.0-migration instead of just -migration. On the other hand, the user has to remember just one option (-source) instead of two.

[lrytz]

Ignoring the cross-compiling variants for now, this creates new in-between scala versions (3.0, 3.1-migration, 3.1). I don't really understand what the -migration version is / does.

• Would 3.1-migration issue warnings for code that works in 3.0, but is an error in 3.1? In this case, that looks like skipping the usual deprecation cycle, so instead the deprecation warning should go in plain 3.0. Or is there some other kind of "migration warning"?
• Or would would 3.1-migration allow code to work (with a warning?) that is an error in 3.1? If so, why not use source 3.0 for that?

[odersky]

@lrytz -migration is intended to help with code migration from one version to the next. How it does that depends on the concrete problem. So far, dotc does any of the following things if in a X-migration source setting:

• turn some things that are allowed in X-1 but errors in X into migration warnings
• change some rules to be more lenient and backwards compatible with X-1
• give some additional warnings where the semantics has changed between X-1 and X
• In conjunction with -rewrite, offer code rewrites from X-1 to X.

It's not the usual deprecation cycle. For the next few versions we need an accelerated scheme to get from one version to the next. After we have stabilized (maybe in 3.1 or 3.2), we will fall back to deprecation cycles, and then we might not need intermediate -migration source versions anymore.

[lrytz]

I think the added complexity of these in-between versions should be avoided if possible.

turn some things that are allowed in X-1 but errors in X into migration warnings

These could be warnins in X-1 instead, or demote the errors to warnings in X. Are there convincing examples where that doesn't work?

change some rules to be more lenient and backwards compatible with X-1

So that would allow using new features of X while still being allowed to break some rules that X-1 doesn't enforce. Again, if enforcing something in X needs a backdoor, that's maybe a sign to move slower, make it a warning first.

additional warnings where the semantics has changed between X-1 and X

That's like scala 2's -Xmigration flag, and is a useful feature for cases when there's no better alternative (change of semantics).

[odersky]

@lrytz All these things are already implemented and used in the migrations. We do not want to change them, they are an essential part of the tooling. The question is only how to specify what should be done. The previous scheme relied on a combinaton of -language:Scala2Compat, -migration, -strict. It was more complex than this PR and less extensible. #8571 proposed to change this to just -source and -migration. This PR uses just -source, but with a more elaborate source naming scheme.

[OlivierBlanvillain]

I like this proposal much more than the previous iteration because it doesn't commit to giving meaning to the -migration flag for future version and makes it very clear that your code base shouldn't be compiled long term with a *-migration scala version.

[odersky]

Going to merge this later today in order to avoid merge conflicts in CB projects (many of these projects had their build settings changed from -language:Scala2Compat to -source 3.0-migration).