Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fields: expand lazy vals during fields, like modules #5294
(follow up for #5141 )
Fields phase fully expands lazy vals and modules
Mixins is relieved of its bitmap emission duties.
Lazy vals remain
Lazy val accessors, fields and bitmaps are now mixed in during the fields phase, which means erasure and specialization get a better look at them. Should we also move mixins before erasure?
@lrytz did the bulk of the work in moving our encoding of local lazy vals to the scheme used by Dotty, based on a suggestion by @DarkDimius. Locking is now down on the holder of the lazy val's value / init bit, instead of on the enclosing class (which had widened from the closure class to the owner of the method, making this more prone to deadlocks).
All lazy vals and modules use double-checked locking, but modules no longer spin off their initialization to a compute method (it's short enough not to interfere with the inlining of the lazy accessor).
Notes from the implementation lab journal
tests / review follow up
follow ups after RC1:
@adriaanm I started looking at implementing scala/scala-dev#133, but it's not clear to me what's the ultimate goal for the lazy val desugaring. Currently, the fields phase creates a variable and a getter for each lazy val. The lazyvals phase then splits up the getter into a getter and a
Also, there's still some duplication between lazyvals and mixin: both have a method
For scala/scala-dev#133, the idea is to expand a local
Should all of this be done in the fields phase? Or during lazyvals?
Thanks! My goal is to move the remaining lazy desugaring from mixin to lazyvals, so that there's no duplication. I have started poking around to convince myself that
currently crashes in backend, will pick it up tomorrow.
I tried rebasing on top of this PR, the result is here: lrytz@3d56b1f. But this revision doesn't pass the test I wrote.
There are a few TODOs in the commit, please take a look. A few more open questions:
How should we proceed?
here's some more wip: https://github.com/lrytz/scala/commits/pr5294 things look a bit messy in the current stage. for example:
note how the slow path is duplicated.
1120e23 is mostly green, except for:
the problems are nulling of single-use lazy fields (I disabled because it nulled too much) and checkinit (haven't integrated that yet)
referenced this pull request
Aug 18, 2016
scalaz compile error
akka compile error
scala-js test failure