-
Notifications
You must be signed in to change notification settings - Fork 1k
Add reference docs for forward compatibility feature #2301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @prolativ for the update of documentation.
The page binary-compatibility
contains useful information, but I think it would be good to summarize somewhere what are the relevant action points for library maintainers, with a concrete example.
``` | ||
|
||
Language imports supersede command-line settings in the source files where they are specified. Only one language import specifying a source version is allowed in a source file, and it must come before any definitions in that file. | ||
Additional information on interoperability and migration between Scala 2 and 3 can be found [here](https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use the {% link ... %}
directives to create internal links.
|
||
In Scala 2 different minor versions of the compiler were free to change the way how they encode different language features in JVM bytecode so each bump of the compiler's minor version resulted in breaking binary compatibility and if a project had any Scala dependencies they all needed to be (cross-)compiled to the same minor Scala version that was used in that project itself. On the contrary, Scala 3 has a stable encoding into JVM bytecode. | ||
|
||
In addition to classfiles the compilation process in Scala 3 also produces files with `.tasty` extension. The [TASTy](https://docs.scala-lang.org/scala3/guides/tasty-overview.html) format is an intermediate representation of Scala code containing full information about sources together with information provided by the typer. Some of this information is lost during generation of bytecode so Scala 3 compilers read TASTy files during compilation in addition to classfiles to know the exact types of values, methods, etc. in already compiled classes (although compilation from TASTy files only is also possible). TASTy files are also typically distributed together with classfiles in published artifacts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe introduce the wording “fully elaborated Scala programs”? TASTy contains fully elaborated Scala programs in the sense that it contains all the information (context parameters and type parameters) that have been inferred by the compiler during the compilation.
scalaOrganization.value %% "scala3-library" % scalaVersion.value, | ||
scalaOrganization.value %% "scala3-library_sjs1" % scalaVersion.value // for Scala.js projects |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this work?
scalaOrganization.value %% "scala3-library" % scalaVersion.value, | |
scalaOrganization.value %% "scala3-library_sjs1" % scalaVersion.value // for Scala.js projects | |
scalaOrganization.value %% "scala3-library" % scalaVersion.value, | |
scalaOrganization.value %%% "scala3-library" % scalaVersion.value // for Scala.js projects |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried this but for some reason this didn't seem to work
E.g. when a project gets compiled with Scala compiler `3.x1.y1` and `-Yscala-release 3.x2` option and then published using sbt | ||
then the standard library in version `3.x1.y1` gets added to the project's dependencies instead of `3.x2.y2`. | ||
When the dependencies are added to the classpath during compilation with Scala `3.x2.y2` the compiler will crash while trying to read TASTy files in the newer format. | ||
A currently known workaround is to modify the build definition of the dependent project by explicitly overriding the version of Scala standard library in dependencies, e.g. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a known workaround that could be applied on the library itself, instead of the modules that depend on the library? Maybe a way to override the package
task in sbt to override the version of the dependency to scala3-library
? Maybe @eed3si9n knows a trick?
966adbd
to
ee3eb6d
Compare
We can add more documentation later when we set some best practices how to make this work smoothly. For now it's still experimental but hopefully we should get some support for this feature in build tools. |
|
||
In Scala 2, different minor versions of the compiler were free to change the way how they encoded different language features in JVM bytecode. So each bump of the compiler's minor version resulted in breaking the binary compatibility, and if a project had any Scala dependencies they all needed to be (cross-)compiled to the same minor Scala version that was used in that project itself. On the contrary, Scala 3 has a stable encoding into JVM bytecode. | ||
|
||
In addition to classfiles the compilation process in Scala 3 also produces files with `.tasty` extension. [TASTy]({% link scala3/guides/tasty-overview.md %}) files are an intermediate representation of Scala programs containing fully elaborated Scala code in the sense that they contain all the information that have been inferred by the compiler during the compilation (like contextual parameters and type parameters). Some of this information is lost during generation of bytecode so Scala 3 compilers read TASTy files during compilation in addition to classfiles to know the exact types of values, methods, etc. in already compiled classes (although compilation from TASTy files only is also possible). TASTy files are also typically distributed together with classfiles in published artifacts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to be picky, but:
In addition to classfiles the compilation process in Scala 3 also produces files with `.tasty` extension. [TASTy]({% link scala3/guides/tasty-overview.md %}) files are an intermediate representation of Scala programs containing fully elaborated Scala code in the sense that they contain all the information that have been inferred by the compiler during the compilation (like contextual parameters and type parameters). Some of this information is lost during generation of bytecode so Scala 3 compilers read TASTy files during compilation in addition to classfiles to know the exact types of values, methods, etc. in already compiled classes (although compilation from TASTy files only is also possible). TASTy files are also typically distributed together with classfiles in published artifacts. | |
In addition to classfiles, the compilation process in Scala 3 also produces files with `.tasty` extension. [TASTy]({% link scala3/guides/tasty-overview.md %}) files represent fully elaborated Scala programs in the sense that they contain all the information that has been inferred by the compiler during the compilation (like contextual parameters and type parameters). Some of this information is lost during the generation of bytecode so Scala 3 compilers read TASTy files during compilation in addition to classfiles to know the exact types of values, methods, etc. in already compiled classes (although compilation from TASTy files only is also possible). TASTy files are also typically distributed together with classfiles in published artifacts. |
ee3eb6d
to
58968f2
Compare
Adapted from scala/scala3#14156