Skip to content
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

Initial steps to generate TASTy for the 2.13 library #17526

Merged
merged 7 commits into from
May 25, 2023

Conversation

nicolasstucki
Copy link
Contributor

@nicolasstucki nicolasstucki commented May 17, 2023

The aim is to have a project that compiles the 2.13 library using Scala 3 to generate the TASTy. This will require a special compilation mode to align with Scala 2 semantics. Then in a later step, we can package the TASTy files in a JAR that can be loaded with the class file JAR of the Scala 2 standard library.

stdlib-bootstrapped project

This PR changes the purpose of stdlib-bootstrapped. Now the project compiles the Scala 2.13 library (only) sources using -Yscala2-stdlib. With this flag, the compiler will generate code that aligns with the Scala 2 version of the library. The main purpose is to have TASTy that contains signatures that align with the Scala 2 library bytecode.

Under -Yscala2-stdlib we currently

  • change the signature of the case class unapply methods,
  • do not emit mirrors,
  • and inline definitions case class _N.

We add MiMa tests to this project to have a better view of the differences between the Scala 2 generated bytecode and the one generated in this PR. The bytecode differences are a useful guide of differences between the TASTy of the library and how applications will link to it.

[skip community_build]

@nicolasstucki nicolasstucki force-pushed the bootstrap-stdlib branch 2 times, most recently from a47d0bc to 19a029b Compare May 19, 2023 08:20
@nicolasstucki nicolasstucki marked this pull request as ready for review May 19, 2023 14:52
project/Build.scala Outdated Show resolved Hide resolved
@@ -735,13 +735,26 @@ object desugar {
.withMods(appMods) :: Nil
}
val unapplyMeth = {
def scala2LibCompatUnapplyRhs(unapplyParamName: Name) =
assert(arity <= Definitions.MaxTupleArity, "Unexpected case class with tuple larger than 22: "+ cdef.show)
val optionApply = Select(Ident(nme.scala), "Option".toTermName)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use scalaDot to get a fully-qualified path.

@smarter
Copy link
Member

smarter commented May 22, 2023

-Yscala2-stdlib should try to set the Scala2x flag on all classes, in particular because this affects erasure: https://github.com/lampepfl/dotty/blob/c205a89c20c3c9d687edfac7fdc5cdec7091d9f6/compiler/src/dotty/tools/dotc/core/TypeErasure.scala#L26-L35

@nicolasstucki
Copy link
Contributor Author

-Yscala2-stdlib should try to set the Scala2x flag on all classes, in particular because this affects erasure:

Yes, this is something that must be done. I did not include it in this first step because setting this flags causes other issues while compiling the library.

IO.delete(classDir / "META-INF")
// TODO What to do with library.properties, LICENSE, NOTICE, rootdoc.txt? Keep? Modify?

// Copy .tasty files from stdlib-2_13-bootstrapped into classDir
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The usual way to add files to the output jar is via mappings: https://www.scala-sbt.org/1.x/docs/Howto-Package.html#Modify+the+contents+of+the+package, this is likely to be more robust for interactive compilation etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we use mappings to filter the .tasty files when packaging stdlib-2_13-bootstrapped.

@@ -134,7 +134,7 @@ jobs:

- name: Cmd Tests
run: |
./project/scripts/sbt ";dist/pack; scala3-bootstrapped/compile; scala3-bootstrapped/test ;sbt-test/scripted scala2-compat/* ;stdlib-bootstrapped/test:run ;stdlib-bootstrapped-tasty-tests/test; scala3-compiler-bootstrapped/scala3CompilerCoursierTest:test"
./project/scripts/sbt ";dist/pack; scala3-bootstrapped/compile; scala3-bootstrapped/test ;sbt-test/scripted scala2-compat/* ;stdlib-bootstrapped/test:run ;stdlib-2_13-bootstrapped/test:run ;stdlib-2_13-tasty-bundle/packageBin ;stdlib-bootstrapped-tasty-tests/test; scala3-compiler-bootstrapped/scala3CompilerCoursierTest:test"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Could we delete stdlib-bootstrapped? If we have both the community build stdlib and stdlib-2_13-bootstrapped then I don't think it serves a purpose anymore
  • Can we merge stdlib-2_13-bootstrapped and stdlib-2_13-tasty-bundle in one project? This might be easier to do when using mappings in the build as I propose in my other comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Could we delete stdlib-bootstrapped? If we have both the community build stdlib and stdlib-2_13-bootstrapped then I don't think it serves a purpose anymore

It still serves the purpose of checking that we can compile the stdlib using Scala 3 semantics/signatures (without -Yscala2-stdlib). It its also a way to check that we are able to compile all Scala 2 and Scala 3 library sources together. This is not something we need to be able to do right now. It could prevent us from breaking something we might need in the long term.

  • Can we merge stdlib-2_13-bootstrapped and stdlib-2_13-tasty-bundle in one project? This might be easier to do when using mappings in the build as I propose in my other comment.

I removed the bundle project. Now we package only the .tasty files in stdlib-2_13-bootstrapped.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It still serves the purpose of checking that we can compile the stdlib using Scala 3 semantics/signatures (without -Yscala2-stdlib). It its also a way to check that we are able to compile all Scala 2 and Scala 3 library sources together.

This is also checked by the stdlib213 community-build project (it relies on https://github.com/scala/scala/blob/2.13.x/project/DottySupport.scala).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, then I guess we can remove it and only keep one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rebased and cleaned up the git history of the changes in the build. Now we only modify the definition of stdlib-bootstrapped.

Scala 2 does not generate the methods `_N`. This is solved by inlining
those calls, which removes the calls to those methods and the definitions
of those methods in the bytecode.
@nicolasstucki nicolasstucki merged commit d077bbd into scala:main May 25, 2023
@nicolasstucki nicolasstucki deleted the bootstrap-stdlib branch May 25, 2023 08:09
nicolasstucki added a commit that referenced this pull request Jun 28, 2023
This adds a temporary workaround (`stdlib-bootstrapped-legacy`) to be
able to generate documentation for the full standard library. In the
future, the documentation will be generated from `stdlib-bootstrapped`
and `scala3-library-bootstrapped` combined.

Fixes #17964
Fixes #17621

Partially reverts #17526
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants