|
|
When reifying certain trees/types reifier might decide that it needs to
introduce auxiliary symbols to represent non-locatable components of types
For example, when reifying a refined type we need to reify the symbols
that correspond to its members (aka RefinedType.decls). Since these symbols
are not stored in pickles, we can't do the usual staticClass(scala.Int) stuff,
and are forced to actually create corresponding symbols inside the reificode
(by "create" I mean literally create, by using newXXXSymbol methods).
It looks like a generally good idea to not only create those symbols naked,
but to also export their type signatures and annotations. However this brings
problems with type inference.
Say, a type of a method A depends on a type tag. To get a type of a type tag,
the compiler needs to expand the corresponding macro (when the macro is being
expanded, symbol A is marked as LOCKED). While reification macro expands,
it might want to reify certain symbol definitions (as explained above). If one
of these definitions is a class that contains method A, we're in trouble,
since reifying the corresponding ClassInfoType will eventually call A.info,
which will produce a cyclic reference error, because A is LOCKED.
An obvious solution is to check whether a reified symbol definition is locked.
If the symbol is locked, then the reifier bails (e.g. by reifying NoType
instead of the actual type signature of the symbol).
Being obvious this solution is also incorrect as illustrated by SI-6204.
Sure we can check whether a symbol itself is locked, but we cannot check
whether or not we reify someone who refers to the locked symbol.
As of such I'm telling the reifier to bail whenever it needs to reify a symbol
definition for a symbol that is not yet complete. Therefore reification
can no longer cause inference of method result types, which eliminates the
underlying problem.
This is a harsh measure, but taking into account that we have an RC planned
within a week, stability trumps completeness.
|
