summaryrefslogtreecommitdiff
path: root/test/files/run/trait-defaults-modules3.scala
Commit message (Collapse)AuthorAgeFilesLines
* Desugar module var and accessor in refchecks/lazyvalsJason Zaugg2015-10-081-0/+8
Rather than leaving it until mixin. The broader motivation is to simplify the mixin phase of the compiler before we get rid of implementatation classes in favour of using JDK8 default interface methods. The current code in mixin is used for both lazy val and modules, and puts the "slow path" code that uses the monitor into a dedicated method (`moduleName$lzyCompute`). I tracked this back to a3d4d17b77. I can't tell from that commit whether the performance sensititivity was related to modules or lazy vals, from the commit message I'd say the latter. As the initialization code for a module is just a constructor call, rather than an arbitraryly large chunk of code for a lazy initializer, this commit opts to inline the `lzycompute` method. During refchecks, mixin module accessors are added to classes, so that mixed in and defined modules are translated uniformly. Trait owned modules get an accessor method with an empty body (that shares the module symbol), but no module var. Defer synthesis of the double checked locking idiom to the lazyvals phase, which gets us a step closer to a unified translation of modules and lazy vals. I had to change the `atOwner` methods to to avoid using the non-existent module class of a module accessor method as the current owner. This fixes a latent bug. Without this change, retypechecking of the module accessor method during erasure crashes with an accessibility error selecting the module var. In the process, I've tweaked a tree generation utility method to wvoid synthesizing redundant blocks in module desugaring.