Definitions.AnyRefModule not available in superaccessors

[Vlad Ureche]

Hi everyone,

I was working on hiding the AnyRef specialization under a flag, as discussed in SI-6103.
I stumbled on the fact that Definitions.AnyRefModule is not available in superaccessors and I don't know how to force it to become available sooner.

If I access Definitions.AnyRefModule in specialization, all is well, but if I access it in superaccessors I get:

uncaught exception during compilation: scala.reflect.internal.FatalError
error: scala.reflect.internal.FatalError: package scala does not have a member object AnyRef
    at scala.reflect.internal.Definitions$DefinitionsClass.scala$reflect$internal$Definitions$DefinitionsClass$$fatalMissingSymbol(Definitions.scala:979)
    at scala.reflect.internal.Definitions$DefinitionsClass.getMemberModule(Definitions.scala:1022)
    at scala.reflect.internal.Definitions$DefinitionsClass.AnyRefModule$lzycompute(Definitions.scala:248)
    at scala.reflect.internal.Definitions$DefinitionsClass.AnyRefModule(Definitions.scala:248)
    at scala.tools.nsc.typechecker.SuperAccessors$SuperAccTransformer.transform(SuperAccessors.scala:239)
    at scala.tools.nsc.typechecker.SuperAccessors$SuperAccTransformer.transform(SuperAccessors.scala:43)

The "AnyRef module" is actually defined in src/library/scala/package.scala as:

  // A dummy used by the specialization annotation.
  val AnyRef = new Specializable {
    override def toString = "object AnyRef"
  }

If I transform that to object AnyRef extends Specializable all goes well, so I imagine there's some magic going on somewhere to transform the val into an object.
I traced the val change to this commit, and it seems the motivation for having a val is that <cite>it's bad juju to place objects inside package objects</cite>. (I'm not kidding, search for juju in the diff)
My questions are:
1) Can we accept the bad juju and make AnyRef an object again?
2) If we need to keep the val, what is the val2object magic incantation so I trigger it earlier?

Any help is greatly appreciated!


Thanks,
Vlad

[Paul Phillips]

On Wed, Jul 25, 2012 at 8:52 AM, Vlad Ureche <vlad....@gmail.com> wrote:

I traced the val change to this commit, and it seems the motivation for having a val is that <cite>it's bad juju to place objects inside package objects</cite>. (I'm not kidding, search for juju in the diff)

There are a bunch of bugs which arise only when you nest objects/classes in package objects.  It's easy to see why there would be bugs if you count the number of calls to "skipPackageObject" and "effectiveOwner" vs. "owner" (each of which is a potential opportunity to incur such a bug) plus there is the bytecode issue and everything that comes with it:

package object foo {
  object Main // backend generates foo.package$Main$

}

package foo {
  object Main // backend generates foo.Main$
}

That's why it's bad juju.  In the case of AnyRef it might be fine to make it an object.  But at the time I couldn't see why it HAD to be, and that's why it isn't.