SymbolInfoParser
Related Docs:
object SymbolInfoParser
| package symboldsl
Accessible members include methods, modules, val/var setters and getters and Java fields.
Accessible members include methods, modules, val/var setters and getters and Java fields.
Translates this type so that all existential types in this type do not refer to the defining class, as they do by default.
Translates this type so that all existential types in this type do not refer to the defining class, as they do by default. Heavy wizardry.
The problem is that when you reify an existential type (with c.reifyType), for example Set[_], the
wildcard is reified as a Symbol whose owner is the class that used that existential type.
This effectively means that the definition of existential type refers the class that used it.
This means that when the type is finally evaluated in some universe, things will blow up if that class is
not visible to that universe.
For example, this is exactly what happens if you use some existential type in the SymbolValidator DSL and
the symbol validator is compiled at runtime using compileSymbolValidator method of ScexCompiler. That dynamically
compiled class is not visible to the Scala compiler through classpath and when it tries to evaluate the reified
type, we have a nice scala.reflect.internal.MissingRequirementError in our face.
Handles @plus and @minus type annotations.
Handles @plus and @minus type annotations.
For example java.util.List[Number@plus] is translated to java.util.List[_ <: Number]
Is this symbol the 'wrapped' field of Java getter adapter?
Is this symbol the 'wrapped' field of Java getter adapter?
Is this tree a path that starts with package and goes through stable symbols (vals and objects)?
Is this tree a path that starts with package and goes through stable symbols (vals and objects)?
Author: ghik Created: 11/14/14.