summaryrefslogtreecommitdiff
path: root/test/scaladoc
diff options
context:
space:
mode:
authorJason Zaugg <jzaugg@gmail.com>2014-01-17 09:27:55 +0100
committerJason Zaugg <jzaugg@gmail.com>2014-01-20 23:16:59 +0100
commit357905c9555f8081784acd1912cf0681b145ca8b (patch)
treeb467214d8084efc48a736f34523405502c2cee06 /test/scaladoc
parent731ed385dea0196305a0c527303649ea0325de63 (diff)
downloadscala-357905c9555f8081784acd1912cf0681b145ca8b.tar.gz
scala-357905c9555f8081784acd1912cf0681b145ca8b.tar.bz2
scala-357905c9555f8081784acd1912cf0681b145ca8b.zip
SI-5954 Invalidate TypeRef cache when opening package object
I noticed that the pos/5954d was tripping a println "assertion". This stemmed from an inconsistency between `TypeRef#{parents, baseTypeSeq}` for a package objects compiled from source that also has a class file from a previous compilation run. I've elevated the println to a devWarning, and changed `updatePosFlags`, the home of this evil symbol overwriting, to invalidate the caches in the symbols info. Yuck. I believe that this symptom is peculiar to package objects because of the way that the completer for packages calls `parents` during the Namer phase for package objects, before we switch the symbol to represent the package-object-from-source. But it seems prudent to defensively invalidate the caches for any symbol that finds its way into `updatePosFlags`.
Diffstat (limited to 'test/scaladoc')
0 files changed, 0 insertions, 0 deletions