Skip to content

Set compiler phase runsBefore to tailcalls #191

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

Merged
merged 4 commits into from
Sep 23, 2019

Conversation

lrytz
Copy link
Contributor

@lrytz lrytz commented Sep 4, 2019

runsAfter is set to fields. However, in reality the phase
assembly algorithm used in 2.12.9 and before, also 2.13.0, places the
GenJavadoc phase right after specialize, which is valid, but probably
not intended.

With some changes in the phase assembly algorithm in 2.13.1, the
GenJavadoc phase was now placed right after fields, which caused
tests to fail.

@lrytz lrytz requested a review from raboof September 4, 2019 11:39
Copy link
Contributor

@raboof raboof left a comment

Choose a reason for hiding this comment

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

Not intimately familiar with the compiler phases, but this looks good and the patch diffs suggest nothing of value was lost.

Can't test right now as it seems publishLocal no longer works and publishLocalSigned doesn't produce ivy metadata (filed #193)

Copy link
Contributor

@raboof raboof left a comment

Choose a reason for hiding this comment

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

Testing with Akka, this seems to introduce could not optimize @tailrec annotated method compiler errors when running sbt -Dakka.genjavadoc.enabled=true unidoc.

@lrytz
Copy link
Contributor Author

lrytz commented Sep 16, 2019

Interesting... I can take a look. Which branch of akka did you use?

@raboof
Copy link
Contributor

raboof commented Sep 16, 2019

I checked with Akka master (bc590af56f39cff358d7a67d28f01e98f05741a8). I did a sbt ++2.12.9 publishLocalSigned of this branch with #197 cherry-picked on top on the genjavadoc side, and updated unidocGenjavadocVersion in project/Doc.scala on the akka side.

@lrytz
Copy link
Contributor Author

lrytz commented Sep 17, 2019

The problem is that adding the javadoc plugin shuffles around the compiler's own phases...

Without the plugin:

$> scalac Test.scala -Vphases
    phase name  id  description
    ----------  --  -----------
        fields  11  synthesize accessors and fields, add bitmaps for lazy vals
     tailcalls  12  replace tail calls by jumps
    specialize  13  @specialized-driven class and method specialization
 explicitouter  14  this refs to outer pointers
       erasure  15  erase types, add interfaces for traits
   posterasure  16  clean up erased inline classes
    lambdalift  17  move nested functions to top level

With the plugin, tailcalls and specialize move to the back and are now after lambdalift, they used to be after fields:

$> scalac -Xplugin:/Users/luc/.ivy2/local/com.typesafe.genjavadoc/genjavadoc-plugin_2.13.0/0.11_2.13.0-M4+58-bb141048+20190917-1239/jars/genjavadoc-plugin_2.13.0.jar Test.scala -Vphases
    phase name  id  description
    ----------  --  -----------
        fields  11  synthesize accessors and fields, add bitmaps for lazy vals
    GenJavadoc  12
 explicitouter  13  this refs to outer pointers
       erasure  14  erase types, add interfaces for traits
   posterasure  15  clean up erased inline classes
    lambdalift  16  move nested functions to top level
     tailcalls  17  replace tail calls by jumps
    specialize  18  @specialized-driven class and method specialization

We really have to clean up the phases list in the compiler, the ordering should not be left to the algorithm. Currently we have

  object tailCalls extends {
    val runsAfter = List("uncurry")

  object fields extends {
    val runsAfter = List("uncurry")

  object explicitOuter extends {
    val runsAfter = List("fields")

that's why tailcalls can move around...

So this PR works for 2.12.10 (tested locally) and 2.13.1 (tested in community build). These two versions include the changes to the phase assembly algorithm that causes breakages without this PR.

So it seems we really need to have two versions here, one for 2.10, 2.11, 2.12.0-2.12.9, 2.13.0, and the other one for 2.12.10+, 2.13.1+.

lrytz added a commit to lrytz/scala that referenced this pull request Sep 17, 2019
explicitouter and specialize both were defining

    val runsRightAfter = Some("tailcalls")

So it was up to the algorithm to define the phase ordering. This can
cause subtle issues, as seen in lightbend/genjavadoc#191.
lrytz added a commit to lrytz/scala that referenced this pull request Sep 17, 2019
explicitouter and specialize both were defining

    val runsRightAfter = Some("tailcalls")

So it was up to the algorithm to define the phase ordering. This can
cause subtle issues, as seen in lightbend/genjavadoc#191.
`runsAfter` is set to `fields`. However, in reality the phase
assembly algorithm used in 2.12.8 and before, also 2.13.0, places the
`GenJavadoc` phase right after `specialize`, which is valid, but probably
not intended.

With some changes in the phase assembly algorithm in 2.13.1, the
`GenJavadoc` phase was now placed right after `fields`, which caused
tests to fail.
@lrytz
Copy link
Contributor Author

lrytz commented Sep 17, 2019

@raboof please take another look? And if you have time, it would be great to try if it works with akka, with both 2.12.9 and 2.12.10, maybe also 2.13.0 and 2.13.1-bin-3987e83 from https://scala-ci.typesafe.com/artifactory/scala-integration, this is our 2.13.1 RC.

@lrytz
Copy link
Contributor Author

lrytz commented Sep 17, 2019

The community build for 2.13.1-bin-3987e83 is also running (https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/2610) and testing the latest revision of this PR (a782143).

@raboof
Copy link
Contributor

raboof commented Sep 23, 2019

Seemed to work for Akka with 2.12.9 and 2.13.0, so let's merge

@raboof raboof merged commit 83b9080 into lightbend:master Sep 23, 2019
@lrytz
Copy link
Contributor Author

lrytz commented Sep 23, 2019

Thank you!

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.

3 participants