method super$++

It looks plausible to be that, but I cannot reproduce it anymore, and I
don't see an obvious code path involving originalName. The crash was due
to not finding the right overload at line 827 in UnPiclers.scala,
returning NoSymbol. I initially thought it's a phase ordering problem,
and names were transformed before the lazy symbol was forced (at the jvm
phase).

iulian

Paul Phillips wrote:
> I noticed this comment in GenJVM in r18060:
>
> // the following call to 'info' may cause certain symbols to fail loading because we're
> // too late in the compilation chain (aliases to overloaded symbols will not be properly
> // resolved, see scala.Range, method super$++ that fails in UnPickler at LazyTypeRefAndAlias.complete
>
> Are you sure that reasoning is complete? I ask because your particular
> example of a method which fails in unpickler -- "super$++" -- is also my
> example of a method of interest in a different context, and that is that
> its expanded name is lossy.
>
> My desktop which has this code on it is still not unpacked so I can't be
> 100% specific, but I have a branch which records every call to
> originalName and expandName and complains if originalName(expandName(x))
> != x. When building scalac, all the complaints are about constructs
> like super.++ because "super$" + "$plus" == "super$$plus" and "$$" is
> also used in name mangling, but for a different purpose.
>
> I hadn't pinpointed what if any issues this was causing so it's been
> sitting there waiting for me to figure that out, but now that I see it
> mentioned by name in a comment I figured I better share what I know.
>
>