There are two key methods in here.
There are two key methods in here.
1) Enter methods such as enterGetterSetter are called from Namer with a tree which may generate further trees such as accessors or implicit wrappers. Some setup is performed. In general this creates symbols and enters them into the scope of the owner.
2) addDerivedTrees is called from Typer when a Template is typed. It completes the job, returning a list of trees with their symbols set to those created in the enter methods. Those trees then become part of the typed template.
A class representing a lazy type with known type parameters.
A class representing a lazy type with known type parameters. ctx
is the namer context in which the
owner
is defined.
Constructing a PolyTypeCompleter for a DefDef creates type skolems for the type parameters and
assigns them to the tparams
trees.
The companion class or companion module of original
.
The companion class or companion module of original
.
Calling .companionModule does not work for classes defined inside methods.
!!! Then why don't we fix companionModule? Does the presence of these methods imply all the places in the compiler calling sym.companionModule are bugs waiting to be reported? If not, why not? When exactly do we need to call this method?
The annotations amongst those found on the original symbol which should be propagated to this kind of accessor.
The annotations amongst those found on the original symbol which should be propagated to this kind of accessor.
A version of Symbol#linkedClassOfClass
that works with local companions, ala companionSymbolOf
.
This trait declares methods to create symbols and to enter them into scopes.
1.0