support Scala 3.2.0 in TASTy Reader

[bishabosha]

It will have a new tasty minor version so will be rejected by nsc.

[SethTisue]

@bishabosha is there time to get this into 2.13.9? (tentative RC date is Mon May 9)

[bishabosha]

The first 3.2.0-RC1 is scheduled for May 17th, the final 3.2.0 stable could be a few months from now so perhaps it should be released in 2.13.10?

[SethTisue]

hmm... the timing is a bit awkward. @lrytz wdyt, does this incline you to delay 2.13.9 to get this in?

(leaving on 2.13.9 milestone for now, until we decide)

[lrytz]

Are there any changes in tasty so far, or is it only the version number check that fails? Are any (more) changes planned or likely to happen? Are changes to tasty always breaking, or are they / could they be benign in that an old 2.13 compiler could safely work with a new tasty?

[bishabosha]

Are there any changes in tasty so far

extension methods will have a new encoding (should not affect scala 2), there will also be a change to the way constructors can be encoded (implications for annotations). A few other things affect only bodies of methods.

is it only the version number check that fails?

not if someone uses an annotation with the new constructor encoding.

Are any (more) changes planned or likely to happen?

not immediately, maybe the erasure of union types. (Int | Nothing)

Are changes to tasty always breaking, or are they / could they be benign in that an old 2.13 compiler could safely work with a new tasty?

some may be ok, but not when they affect either erasure, annotations, flags, or the byte format itself.

[SethTisue]

suppose we waited for 3.2.0-RC1, then released 2.13.9. would that have a reasonably good chance of being a sufficient amount of waiting?

waiting until May 17 is only a short delay, but waiting 6 more weeks after that is a considerable delay.

[SethTisue]

We discussed this at the Scala 2 team meeting yesterday, and we were all most comfortable with delaying 2.13.9 until after 3.2.0 final is out, rather than take any risks in this area.

[bishabosha]

TODO: support erasure of Int | Nothing scala/scala3#14971 - probably no action to take here as we reject unions currently.

[bishabosha]

also test against: scala/scala3#14840

[SethTisue]

@bishabosha now that 3.2.0-RC1 is out, is it time to address this?

to be clear: 2.13.9 would still wait for 3.2.0 final. but we should verify ahead of time that we'll be ready, yes?

[bishabosha]

yes I will start testing tomorrow

[bishabosha]

@SethTisue I have hit a curious case that affects any time some sort of enum/case-class from Scala 3 is referenced.

• SpecializeTypes phase forces every symbol in existence, which unfortunately then forces scala.deriving.Mirror.fromProductTyped, (new API in 3.2)
• This sets of a chain of forcing scala.deriving.Mirror.ProductOf which then sees the upper bounds of MirroredElemTypes <: scala.Tuple and tasty unpickler panics that it can't support that (due to erasure issues) - will need to rethink how to be more lazy here.

Im thinking I should do it by instead of throwing an error - I should try an set a compiletimeOnly annotation on the closest enclosing public definition - the only problem is containing knock on errors when we can't meaningfully use the problematic type

[SethTisue]

@bishabosha will we need one more PR after 3.2.0 final is out? if so, we should leave the ticket open

[bishabosha]

Ok sure, I will remove the TASTy special case for 3.2.0 final, however it would not be necessary

[SethTisue]

@bishabosha 3.2.0 is on Maven Central; can you submit the PR now?

[bishabosha]

Ill do that now