Generalize function symbol synthesis logic #2398
Conversation
We will need other synthesized symbols down the road (e.g. function types in phantom universes). With this commit one can provide for that by installing a synthesizer in a scope.
| lazy val ScalaPackageClass = { | ||
| val cls = ScalaPackageVal.moduleClass.asClass | ||
| cls.info.decls.openForMutations.useSynthesizer( | ||
| name => ctx => |
There was a problem hiding this comment.
Where is the ctx parameter used here?
There was a problem hiding this comment.
This might be needed for other synthetic functions like the functions that take phantom parameters.
| @@ -204,6 +210,12 @@ object Scopes { | |||
| */ | |||
| private var elemsCache: List[Symbol] = null | |||
|
|
|||
| /** The synthesizer to be used, or `null` if no synthesis is done on this scope */ | |||
| private var synthesize: SymbolSynthesizer = null | |||
There was a problem hiding this comment.
Note that with both scalac and doty, not using private[this] here will generate a pair of getter and setter, this is arguably something that we should fix in the compiler since private[this] and private should be considered equivalent in an object.
There was a problem hiding this comment.
Let's leave it like this. Do we have an issue for this?
| * the given name in the given context. Returns `NoSymbol` if the | ||
| * no symbol should be synthesized for the given name. | ||
| */ | ||
| type SymbolSynthesizer = Name => Context => Symbol |
There was a problem hiding this comment.
For efficiency, I would consider using (Name, Context) => Symbol instead, but that might be a premature optimization.
There was a problem hiding this comment.
I would assume that with our current simple use cases the JVM must be capable of inlineing the this additional lambda. Seem a bit premature optimization.
|
LGTM |
We will need other synthesized symbols down the road (e.g.
function types in phantom universes). With this commit one
can provide for that by installing a synthesizer in a
scope.