summaryrefslogtreecommitdiff
path: root/.mailmap
diff options
context:
space:
mode:
authorLukas Rytz <lukas.rytz@gmail.com>2016-10-26 17:21:02 +0200
committerLukas Rytz <lukas.rytz@gmail.com>2016-10-27 10:42:00 +0200
commit5751763261312bfadabb91b15b3ed826648023af (patch)
tree4191dce74832537fb22c17d295f800c5809d6d2b /.mailmap
parent762bcdcd7fcdf75d7645b4d8a3d14a2d60ed1fd0 (diff)
downloadscala-5751763261312bfadabb91b15b3ed826648023af.tar.gz
scala-5751763261312bfadabb91b15b3ed826648023af.tar.bz2
scala-5751763261312bfadabb91b15b3ed826648023af.zip
Classfile parser and unpickler require class and module symbol arguments
In SymbolLoaders, when seeing a classfile `Foo.class`, we always (unconditionally) create 3 symbols: a class, a module and a module class. Some symbols get invalidated later (`.exists`). Until now, the classfile parser (and unpickler) received the "root" symbol as argument, which is the symbol whose type is being completed. This is either the class symbol or the module symbol. The classfile parser would then try to lookup the other symbol through `root.companionClass` or `root.companionModule`. Howver, this lookup can fail. One example is scala-dev#248: when a type alias (in a package object) shadows a class symbol, `companionClass` will fail. The implementations of the classfile parser / unpickler assume that both the `clazz` and the `staticModule` symbols are available. This change makes sure that they are always passed in explicitly. Before this patch, in the example of scala-dev#248, the `classRoot` of the unpickler was NoSymbol. This caused a bug when unpickling the module class symbol, causing a second module class symbol to be created mistakingly. The next commit cleans up this logic, more details there. This second symbol would then cause the crash in the backend because it doesn't have an `associatedFile`, therefore `isCoDefinedWith` would spuriously return `true`.
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions