summaryrefslogtreecommitdiff
path: root/test/files/pos/t6204-b.scala
diff options
context:
space:
mode:
authorEugene Burmako <xeno.by@gmail.com>2012-08-08 13:20:09 +0200
committerEugene Burmako <xeno.by@gmail.com>2012-08-09 01:06:11 +0200
commit4ced74a5eece7ff27e24b6dcd5f607c130fb1342 (patch)
treee51a72604c8e10ed7e313b4553b65da34973f01e /test/files/pos/t6204-b.scala
parent2ba6774766ec695fef36e605472100922b56b91f (diff)
downloadscala-4ced74a5eece7ff27e24b6dcd5f607c130fb1342.tar.gz
scala-4ced74a5eece7ff27e24b6dcd5f607c130fb1342.tar.bz2
scala-4ced74a5eece7ff27e24b6dcd5f607c130fb1342.zip
SI-6204 reifier no longer causes cyclic errors
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.
Diffstat (limited to 'test/files/pos/t6204-b.scala')
-rw-r--r--test/files/pos/t6204-b.scala10
1 files changed, 10 insertions, 0 deletions
diff --git a/test/files/pos/t6204-b.scala b/test/files/pos/t6204-b.scala
new file mode 100644
index 0000000000..86094d1a19
--- /dev/null
+++ b/test/files/pos/t6204-b.scala
@@ -0,0 +1,10 @@
+import scala.reflect.runtime.universe._
+
+object Bosh {
+ def Besh {
+ new {
+ val t = typeOf[Option[_]]
+ val x = t
+ }
+ }
+} \ No newline at end of file