Cannot test with `r3.1` and then `c3.1.0`

Compiler version

300a8b688b9d671341dad58b097367037015b656

Minimized example

// tests/pos/mytest/A_1_r3.1.scala
class Foo

// tests/pos/mytest/B_2_c3.1.0.scala
class Bar extends Foo

Output

sbt> testCompilation tests/pos/mytest
... 
No files matched "mytest" in test                                   
[info] Test dotty.tools.dotc.CompilationTests.posMacros started
Compilation failed for: 'tests/pos/mytest'                   
[=======================================] completed (1/1, 1 failed, 3s)
...

Expectation

Should pass.

Should also show the error (see #14303).

[prolativ]

IMO we have two separate problems which we are unnecessarily trying to solve with a single mechanism:

1. Which version of the compiler should be able to write and read which version of TASTy?
2. How to prevent TASTy files generated by snapshot/experimental compilers from leaking into production/non-experimental codebases?

I think the -Yas-experimental solution alone wouldn’t solve our current problem with tests if we don’t change the versioning scheme of TASTy. Let’s have a look at the example from the beginning of this thread:

TASTy signature has wrong version.
 expected: {majorVersion: 28, minorVersion: 1}
 found   : {majorVersion: 28, minorVersion: 2 [unstable release: 1]}

This TASTy file was produced by an unstable release.
To read this TASTy file, your tooling must be at the same version.
The TASTy file was produced by Scala 3.1.2-RC1-bin-SNAPSHOT-nonbootstrapped-git-c3eaadd.

Here we’re compiling some code with -scala-output-version 3.1 flag using a locally built experimental compiler and then we’re checking if the non-experimental published compiler 3.1.0 can consume the produced TASTy. Even if -Yas-experimental allowed for consumption of experimental TASTy files by non-experimental compilers there would be a mismatch in minor TASTy version anyway

 expected: {majorVersion: 28, minorVersion: 1 [unstable release: 1]}
 found   : {majorVersion: 28, minorVersion: 2 [unstable release: 1]}

What’s more, -Yas-experimental as a boolean flag would be ambiguous because experimental version can be greater than 1.

I would then suggest the following solutions to the problems I mentioned at the beginning of this comment:

1. Replace the current versioning scheme of TASTy with the one that I described earlier, e.g. (with -SN meaning -SNAPSHOT or -NIGHTLY; TASTy versions with e suffix are experimental):

scala version	3.2.0-SN	3.2.0-RC1	3.2.0	3.2.1-SN	3.2.1-RC1	3.2.1	3.2.2-SN	3.2.2-RC1	3.2.2	3.3.0-SN
TASTy version (current)	28.2e	28.2e	28.2	28.3e	28.2	28.2	28.3e	28.2	28.2	28.3e
TASTy version (new)	28.2e	28.2e	28.2	28.2	28.2	28.2	28.2	28.2	28.2	28.3e

1. a) Add a check while reading TASTy files to ensure that VersionString is not an experimental/unstable version when the compiler itself is stable.
2. b) Add -Yas-experimental flag (we might yet think if this is the best name), which:

• allows compilers in stable versions to read TASTy files in a stable format produced by an experimental compiler
• sets VersionString of TASTy files produced by a stable compiler so that these files look as if they were produced by an experimental compiler version without actually changing the TASTy version (major, minor and experimental fields).

[nicolasstucki]

An alternative that might be simpler is to allow stable compiler versions to compile as if they were unstable. We could add a -Yas-experimental that would make the compiler behave as a snapshot or nightly: accepting other nightly dependencies but generating TASTy marked as experimental.

The advantage of this approach is that we would never be able to publish a TASTy marked as stable from a non-stable version of the compiler. Keeping this strong guarantee seems paramount for the correct behavior published stable artifacts.