3.0.0-M2 + 2.13.4 = TASTy signature has wrong version

[dwijnand]

reproduction steps

using Scala 2.13.4 and 3.0.0-M2,

$ mm A.scala B.scala
==> A.scala <==
package foo

class A

==> B.scala <==
package bar

class B extends foo.A
$ scalac3 A.scala
$ scalac -2.13.4 -Ytasty-reader B.scala
error: error while loading A, class file './foo/A.class' is broken
(class scala.tools.tasty.UnpickleException/TASTy signature has wrong version.
 expected: 24.0
 found   : 25.1)
B.scala:3: error: illegal inheritance;
 self-type bar.B does not conform to foo.A's selftype foo.A
class B extends foo.A
                    ^
2 errors

problem

I wasn't expecting 3.0.0-M2 to make the Tasty Reader functionality just shipped in 2.13.4 be unusable (@bishabosha's baby.)

notes

(Originally reported indirectly by @mpilquist.)

What to do? What to do immediately for the last pre-releases of Scala 3 doesn't matter so much. But what's important are the releases after that: minor releases (3.1/3.2), patch releases (3.0.1/3.0.2), and any pre-releases those might have.

@sjrd gave some thought as to whether it would be possible to untangle the tasty reader from living inside the compiler, such that it can be released outside of Scala's release cadence. But largely it wasn't initially pursued because the requirements overreach what the plugin infrastructure allows for.

I (@dwijnand) think we might be able to manage this sufficiently well by making sure that any Scala 3 release that bumps the format (just minor releases, I think/hope) is preceded by a 2.13 release that can parse it. But @smarter had some resistance to such coupling.

Any more ideas or thoughts?

[smarter]

But @smarter had some resistance to such coupling.

I think there's pros and cons to both approach and I don't have strong feelings either way (that is, I think either would be fine).

Pros of moving to a plugin (assuming it's technically feasible without major work on the plugin infrastructure):

• We can align plugin releases with tasty bumps
• We can fix bugs in the tasty reader without waiting a couple of months for a new scala 2 release
• This plugin could live in the dotty repo and be part of our CI, this way we can make sure it's always aligned with the latest tasty version and testing of various scala sandwiches becomes easier (the current situation isn't great in that respect: Fix #9970: Reconcile how Scala 3 and 2 decide whether a trait has $init$. scala3#10530 (comment))

Cons of moving to a plugin:

• Users have to add a plugin to their build, and remember to update it when a new release is out.
• Users might feel that the support is less "official" and production-worthy if they have to enable a plugin (on the other hand, they're used to it if they use Scala.js)
• The plugin can't easily be a part of the Scala 2 CI anymore (it would have to be built from source at least).

[SethTisue]

@bishabosha is it safe to assume that you'll submit a followup to scala/scala#9394 with 3.0.0-RC1 support, so we can release 2.13.5 not long after 3.0.0-RC1 comes out?

[bishabosha]

@SethTisue Yes, I will make a follow up as soon as the Tasty is stabilised for 3.0.0-RC1 release.

[SethTisue]

fixed by scala/scala#9501