-
Notifications
You must be signed in to change notification settings - Fork 379
Add Scala 2.12 support #1877
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
Add Scala 2.12 support #1877
Conversation
For the issue with
|
nscplugin/src/main/scala/scala/scalanative/nscplugin/NirGenExpr.scala
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,77 @@ | |||
/* |
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.
Are the overrides just standard for 2.12
even in the Scala repo?
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.
Hmm, what do you mean?
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 am just asking a general question about why these are here. They are not changed for Scala Native are they?
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.
Oh yeah, we leave them as is. Basically, where applicable, I applied the changelog from the overrides-2.11
to the 2.12 files.
3d1e5ce
to
237e427
Compare
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.
This is a first review. I still need to really understand what's happening now in the linker for default methods.
5b9a74f
to
9717b6c
Compare
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.
The changes in commit 9f7d2fc were introduced because IntelliJ IDEA treats inline
as a keyword, thus the whole files are red and impossible to work with.
final val compat: Int = 4 // a.k.a. MAJOR version | ||
final val revision: Int = 7 // a.k.a. MINOR version | ||
final val compat: Int = 5 // a.k.a. MAJOR version | ||
final val revision: Int = 8 // a.k.a. MINOR version |
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.
We had increased the revision
when we introduced reflection. We did not have a release in between, but I figured I would increase it again with compat
, since this is a separate PR (i.e. commit hash).
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.
Shouldn't be 5.0
instead of 5.8
?
How does semantic versioning work here?
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.
It should definitely be 5.0 if we are actually breaking backward binary compat. But if we are doing so, we must make that into a separate commit (hence PR) that also removes all the deserialization hacks that were introduced so far.
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.
Hmm, okay. So, are we changing the increment behaviour described in the docstring above?
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.
Let's keep the system in place for now, hence leave 5.8.
Hi. I was wondering if this pr is been under active review. Is there anything pending that community can take a stab at ? |
@ikamthania Hey, it's still under review. I hope we can merge it (as well as other remaining 0.4.0 blockers) and make a release by end of this month |
Thanks for update. No issues. These things take time understandably. |
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 finally dedicated enough continuous time to properly review this.
This looks very good. I only minor comments here and there. I'm looking forward to merging it :)
@@ -86,7 +86,7 @@ trait Opt { self: Interflow => | |||
val retty = rets match { | |||
case Seq() => Type.Nothing | |||
case Seq(ty) => ty | |||
case tys => Sub.lub(tys) | |||
case tys => Sub.lub(tys, Type.Ref(Global.Top("java.lang.Object"))) |
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.
This is not resolve. We need to pass what used to be origRetty
as the second argument to Sub.lub
on this line (moving the computation of origRetty
above val retty = ...
.
case tys => Sub.lub(tys, Type.Ref(Global.Top("java.lang.Object"))) | |
case tys => Sub.lub(tys, origRetty) |
Then we can remove resRetty
and use retty
on the last line of the method instead.
The current changes are sound, but they removed the type specialization entirely, instead of taking advantage of what Sub.lub
can do for us.
tools/src/main/scala/scala/scalanative/linker/ClassLoader.scala
Outdated
Show resolved
Hide resolved
This will also need to be rebased on master to sit on top of #1912. |
b080d1a
to
4d05ca7
Compare
There seems to be a test failing in |
From what I can see there is problem with mangled name of closure, exactly it's order of it's arguments: And here's actual method:
I'm sure that's not a problem with our mangling logic (cause it passes other tests) I would suggest to change test definition to expect method signature in both orders on arguments. I can provide patch resolving this issue tomorrow. |
ca6b029
to
69451a4
Compare
This should be ready for another pass @sjrd. I think that all the comments are resolved and the CI seems to be green! |
import scala.tools.nsc.settings._ | ||
ScalaVersion.current match { | ||
case SpecificScalaVersion(2, 11, _, _) => | ||
HashMethods.foreach(addPrimitive(_, HASH)) |
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 was not able to use the sbt-buildinfo plugin here to condition for the Scala version, because it resulted to an infinite recursion in sbt when resolving the projects that depend on nscplugin
(tried to enable sbt-buildinfo for nscplugin
).
I went with nsc.settings.ScalaVersion
instead. I don't know if the latter has any version guarantees.
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.
Ship it!
Thank you @errikos for this huge work!
The Scala 2.12 changelog can be found at https://www.scala-lang.org/news/2.12.0/ This PR takes into account all the changes and adapts them for Scala Native. --- Lambdas In order to keep the NIR changes to a minimum, we continue generating a `FunctionN` class with an `apply` method for each lambda. All the lambda captures are stored inside the class instance and initialised via its constructor. The `apply` method calls the generated `$anonfun` method, also extracting and forwarding the captures. --- NIR changes Scala 2.12 now compiles trait methods as default methods in Java interfaces. This means that the NIR was enhanced to support default methods. The biggest impact of that is found in the reachability analysis (`Reach.scala`). --- Scala 2.11 cross-compilation In order to keep the project compilable with Scala 2.11, a `scala.scalanative.nscplugin.NirCompat` component is introduced in `nscplugin`. This allows the compiler plugin to function with both Scala 2.11 and 2.12. In addition, some tests need to know under which Scala version they are running. We use `sbt-buildinfo` to provide Scala version information to the projects that need them (mainly for `unit-tests` and `tools` tests). --- Co-authored-by: Denys Shabalin <denys.shabalin@epfl.ch>
This reverts commit 6f57cda.
This reverts commit 6f57cda.
The Scala 2.12 changelog can be found at https://www.scala-lang.org/news/2.12.0/ This PR takes into account all the changes and adapts them for Scala Native. --- Lambdas In order to keep the NIR changes to a minimum, we continue generating a `FunctionN` class with an `apply` method for each lambda. All the lambda captures are stored inside the class instance and initialised via its constructor. The `apply` method calls the generated `$anonfun` method, also extracting and forwarding the captures. --- NIR changes Scala 2.12 now compiles trait methods as default methods in Java interfaces. This means that the NIR was enhanced to support default methods. The biggest impact of that is found in the reachability analysis (`Reach.scala`). --- Scala 2.11 cross-compilation In order to keep the project compilable with Scala 2.11, a `scala.scalanative.nscplugin.NirCompat` component is introduced in `nscplugin`. This allows the compiler plugin to function with both Scala 2.11 and 2.12. In addition, some tests need to know under which Scala version they are running. We use `sbt-buildinfo` to provide Scala version information to the projects that need them (mainly for `unit-tests` and `tools` tests). --- Co-authored-by: Denys Shabalin <denys.shabalin@epfl.ch>
The Scala 2.12 changelog can be found at https://www.scala-lang.org/news/2.12.0/ This PR takes into account all the changes and adapts them for Scala Native. --- Lambdas In order to keep the NIR changes to a minimum, we continue generating a `FunctionN` class with an `apply` method for each lambda. All the lambda captures are stored inside the class instance and initialised via its constructor. The `apply` method calls the generated `$anonfun` method, also extracting and forwarding the captures. --- NIR changes Scala 2.12 now compiles trait methods as default methods in Java interfaces. This means that the NIR was enhanced to support default methods. The biggest impact of that is found in the reachability analysis (`Reach.scala`). --- Scala 2.11 cross-compilation In order to keep the project compilable with Scala 2.11, a `scala.scalanative.nscplugin.NirCompat` component is introduced in `nscplugin`. This allows the compiler plugin to function with both Scala 2.11 and 2.12. In addition, some tests need to know under which Scala version they are running. We use `sbt-buildinfo` to provide Scala version information to the projects that need them (mainly for `unit-tests` and `tools` tests). --- Co-authored-by: Denys Shabalin <denys.shabalin@epfl.ch>
Summary
Add Scala 2.12 support for Scala Native. You can consult the Scala 2.12 changelog here. This PR takes into account all the changes and adapts them for Scala Native.
Lambdas
In order to keep the NIR changes to a minimum, we continue generating a
FunctionN
class with anapply
method for each lambda. All the lambda captures are stored inside the class instance and initialised via its constructor. Theapply
method calls the generated$anonfun
method, also extracting and forwarding the captures.NIR compatibility
Scala 2.12 now compiles trait methods as default methods in Java interfaces. This means that the NIR compiled with 2.12 is not compatible with that compiled with 2.11.
Scala 2.11 cross-compilation
In order to keep the project compilable with Scala 2.11, a
scala.scalanative.nscplugin.NirCompat
component is introduced innscplugin
. This allows the compiler plugin to function with both Scala 2.11 and 2.12.In addition, some tests need to know under which Scala version they are running. We use
sbt-buildinfo
to provide Scala version information to the projects that need them (mainly forunit-tests
andtools
tests).