scala / scala-dev

Scala 2 team issues. Not for user-facing bugs or directly actionable user-facing improvements. For build/test/infra and for longer-term planning and idea tracking. Our bug tracker is at https://github.com/scala/bug/issues
Apache License 2.0
130 stars 15 forks source link

Promote `-Ytasty-reader` to `-Xtasty-reader`? #862

Open SethTisue opened 7 months ago

SethTisue commented 7 months ago

we initially added it as -Y because it was new, but the TASTy Reader is here to stay and there aren't important known bugs in it

for 2.13.14, can we switch to making -Ytasty-reader a deprecated alias for -Xtasty-reader?

the context for this is that in both the Scala 2 and 3 worlds, we are trying to create an expectation that -X flags are normal to use and -Y is experimental and/or flaky and/or internal stuff

the Scala 3 project is in the process of removing or renaming as many -Y flags as possible. making this change would IMO also be consistent with our own history of cut back on -Y

@bishabosha @lrytz opinions?

som-snytt commented 7 months ago

👍 although we might need to call it tastx. I did not realize it was -Y for flakY. Offering my feedback unsolicited.

bishabosha commented 7 months ago

does it need to be a flag still? (I agree with changing to -Xtasty-reader - I think its pretty stable at this point)

SethTisue commented 7 months ago

Oh, like it would just be enabled by default? Hmm... yeah, let's discuss.

What's the downside? I guess having the flag means it's always explicit whether you are using it. If it's enabled by default then you could have a Scala 3 artifact somewhere in your dependency tree without even realizing it. But maybe that's actually okay. If the dependency works, then great. If it doesn't work, you'll get an error — will the error always make it clear that a Scala 3 artifact is involved and the TASTy reader is in play?

SethTisue commented 7 months ago

Of course there's real upside as well: if a library author writes their library in the supported subset of Scala 3 with the intent of having it be usable from Scala 2, it's a bummer if they have to tell their users to not only use for2_13Use3 when adding the dependency, but also to add the flag. It's a barrier that's probably one of the factors preventing people from publishing such libraries (I'm not aware of any, are you?).

But when I start thinking about transitive dependencies I get a little nervous.

som-snytt commented 7 months ago

Dale made boolean flags that can default to true, so you could -Xtasty-reader:false if you need to turn it off.

bishabosha commented 7 months ago

Actually it is likely the user will immediately know if they have TASTy on the classpath because the new classpath loader will prefer tasty files over class files whenever they are available

Edit: right but at present they will get told to turn on the flag.

Any error specifically related to incompatible Scala 3 features is prefixed with some error like "incompatible Scala 3 type" or "unexpected tasty version... this was compiled by Scala 3.5.1"

lrytz commented 7 months ago

the user will immediately know if they have TASTy on the classpath because the new classpath loader will prefer tasty files

That's the case right now, but if we enable the tasty reader by default the compiler doesn't make any noise about reading tasty files.

If a project directly uses a Scala 3 artifact it has to use for2_13Use3, right? How about using a _2.13 library that itself has a dependency on a _3 artifact?

If we actually recommend to publish _3 libraries for use with 2.13, I think the feature should be enabled by default. How is that currently, what does the documentation say? Are there tools for library authors on Scala 3 to ensure their tasty is compatible with 2.13?

bishabosha commented 7 months ago

Are there tools for library authors on Scala 3 to ensure their tasty is compatible with 2.13?

Nothing as far as I am aware, but tasty-query is probably the base to build it on.

There are some subtleties to such a tool if we make one.

Currently the Tasty-reader is designed to be lazy, i.e. it only checks symbols that you actually use in code. So as a whole the scala3-library_3 would fail to meet the standards of "Scala 2.13 compatible", however some parts are necessary for Scala 2 code to interact with basically any data structures, such as scala.deriving.Mirror.Sum/Product being added as parent classes of case class / enum needs to work, (however trying to access an incompatible member such as MirroredElemTypes will fail)

So in this sense what would be a sensible check to enforce?