Hiding AnyRef specialization under a flag #1025
Conversation
ghost
assigned
|
Started jenkins job pr-rangepos at https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/22/ |
|
Started jenkins job pr-scala-testsuite-linux-opt at https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/720/ |
|
jenkins job pr-rangepos: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/22/ |
|
jenkins job pr-scala-testsuite-linux-opt: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/720/ |
|
The strategy seems inordinately indirect and complicated. Maybe there is a good reason for it, but I can't be the guy to sign off on this. |
|
Since the "I didn't specialize on AnyRef" information must be available for future compilations we need to do something about it before pickler. There are two possibilities:
Also, looking at the size of the pickled information favors solution 2: for the most common annotation,
If you have a better suggestion on how to do it, I'd love to hear it. But that's the least complicated solution I could come up without spreading the specialization code all over the compiler. |
|
I had another look at the diff and I noticed I let the changes in Definitions.scala from #999 slipped into this patch. I will resubmit the patch without those changes. @paulp: please have another look at this, as it is important that we don't ship 2.10 with the AnyRef specialization on by default, which would prevent java users from using Function, Tuple and all other AnyRef-specialized classes (https://issues.scala-lang.org/browse/SI-5976) - Unless you can fix mixin before the release, better disable AnyRef specialization... |
The current AnyRef specialization is still fragile, so we'll let the users choose whether to use it or not via the -Xanyref-specialization compiler flag. Source code can always be compiled against a previously AnyRef-specialized classes, but will only be AnyRef-specialized itself if the flag is set. In this patch, an anti-annotation is introduced to mark the fact that AnyRef specialization should be excluded (@specializedExcludeAnyRef). This anti-specialization annotation is added automatically by the compiler to all @specialized type parameters, iregardless of whether the type parameter is going to be specialized on AnyRef or not. The reason is that the logic necessary to decode the types involved in the specialization should not be moved outside SpecializeTypes.scala. Once @specializedExcludeAnyRef is set (in superaccessors) and pickled into the class file, all further scalac runs will specialize the signature for all given types except AnyRef. The instrument.jar archive is generated from the current source, thus there's no need for an extra bootstrapping commit. Review by @paulp and @non.
|
PLS REBUILD ALL |
|
Started jenkins job pr-rangepos at https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/56/ |
|
Started jenkins job pr-scala-testsuite-linux-opt at https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/760/ |
|
jenkins job pr-rangepos: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/56/ |
|
jenkins job pr-scala-testsuite-linux-opt: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/760/ |
|
I will come up with another pull request that only removes the AnyRef specialization from the Scala library. |
As discussed in scala#999, scala#1025 and https://groups.google.com/forum/?hl=en&fromgroups#!topic/scala-internals/5P5TS9ZWe_w instrumented.jar is generated from the current source, there's no need for a bootstrap commit. Review by @paulp.
3 participants
The current AnyRef specialization is still fragile, so we'll let the
users choose whether to use it or not via the -Xanyref-specialization
compiler flag. Source code can always be compiled against a previously
AnyRef-specialized classes, but will only be AnyRef-specialized itself
if the flag is set.
In this patch, an anti-annotation is introduced to mark the fact that
AnyRef specialization should be excluded (@specializedExcludeAnyRef).
This anti-specialization annotation is added automatically by the
compiler to all @specialized type parameters, iregardless of whether
the type parameter is going to be specialized on AnyRef or not. The
reason is that the logic necessary to decode the types involved in the
specialization should not be moved outside SpecializeTypes.scala.
Once @specializedExcludeAnyRef is set (in superaccessors) and pickled
into the class file, all further scalac runs will specialize the
signature for all given types except AnyRef.
The instrument.jar archive is generated from the current source, thus
there's no need for an extra bootstrapping commit.
Review by @paulp and @non.