Allow for the overriding of objects.

Various and sundry manipulations to allow for objects to be overridden
when the mood is right. It is not enabled by default.

The major contributor of change turned out to be the decoupling of
the FINAL flag (and the "isFinal" test which examines only that flag)
and the many semantics which were attributed to this interpretation
of finality in different circumstances. Since objects no longer have
the FINAL flag automatically applied (only top-level objects and those
marked final in source code do) we need apply a more nuanced test.

Fortunately there is such a nuanced test: isEffectivelyFinal,
which is always true if the FINAL flag is set but also in various
other circumstances. In almost every case, you should be testing
"isEffectivelyFinal", not "isFinal".

To enable overridable objects, use:

  -Yoverride-objects
  -Xexperimental      // includes the above and others

Remain to be done: working out transition logistics. Most likely this
would involve bumping the scala signature version, and all objects in
versions before that would be assumed final.

Review by moors.

1 files changed, 1 insertions, 70 deletions

diff --git a/src/library/scala/reflect/generic/HasFlags.scala b/src/library/scala/reflect/generic/HasFlags.scala
index 7f869bfdc2..33d0a51243 100644
--- a/src/library/scala/reflect/generic/HasFlags.scala
+++ b/src/library/scala/reflect/generic/HasFlags.scala
@@ -6,76 +6,7 @@
 package scala.reflect
 package generic
 
-/** ISSUE #1: Flag names vs. Test method names
- *
- *  The following methods from Symbol have a name of
- *  the form isFoo where FOO is the name of a flag, but where the method
- *  body tests for more than whether the flag is set.
- *
- *  There are two possibilities with such methods.  Either the extra
- *  tests are strictly to partition among overloaded flags (which is
- *  the case we can live with in the short term, if each such flag's
- *  partitioning assumptions are documented) or they aren't.
- *
- *  The second case implies that "x hasFlag FOO" and "x.isFoo" have
- *  different semantics, and this we can't live with, because even if
- *  we're smart enough to avoid being tripped up by that, the next guy isn't.
- *
- *  No extreme measures necessary, only renaming isFoo to something
- *  which hews more closely to its implementation.  (Or renaming the flag.)
- *
-    // Defined in the compiler Symbol
-    //
-    final def isLabel = isMethod && !hasAccessorFlag && hasFlag(LABEL)
-    final def isLocal: Boolean = owner.isTerm
-    final def isModuleVar: Boolean = isVariable && hasFlag(MODULEVAR)
-    final def isStable =
-      isTerm &&
-      !hasTraitFlag &&
-      (!hasFlag(METHOD | BYNAMEPARAM) || hasFlag(STABLE)) &&
-      !(tpe.isVolatile && !hasAnnotation(uncheckedStableClass))
-    final def isStatic: Boolean =
-      hasFlag(STATIC) || isRoot || owner.isStaticOwner
-    override final def isTrait: Boolean =
-      isClass && hasFlag(TRAIT | notDEFERRED)     // A virtual class becomes a trait (part of DEVIRTUALIZE)
-
-    // Defined in the library Symbol
-    //
-          def isTrait: Boolean = isClass && hasFlag(TRAIT) // refined later for virtual classes.
-    final def isContravariant = isType && hasFlag(CONTRAVARIANT)
-    final def isCovariant = isType && hasFlag(COVARIANT)
-    final def isMethod = isTerm && hasFlag(METHOD)
-    final def isModule = isTerm && hasFlag(MODULE)
-    final def isPackage = isModule && hasFlag(PACKAGE)
- *
- */
-
-/** ISSUE #2: Implicit flag relationships must be made explicit.
- *
- *  For instance, every time the MODULE flag is set, the FINAL flag is
- *  set along with it:
- *
-   .setFlag(FINAL | MODULE | PACKAGE | JAVA)
-   .setFlag(FINAL | MODULE | PACKAGE | JAVA).setInfo(rootLoader)
-   new ModuleSymbol(this, pos, name).setFlag(MODULE | FINAL)
-   new ModuleSymbol(this, pos, name).setFlag(MODULE | FINAL)
-   val m = new ModuleSymbol(this, pos, name).setFlag(MODULE | FINAL)
-   setFlag(module.getFlag(ModuleToClassFlags) | MODULE | FINAL)
-   sourceModule.flags = MODULE | FINAL
-
- * However the same is not true of when the MODULE flag is cleared:
-
-    sym.resetFlag(MODULE)
-    .setFlag(sym.flags | STABLE).resetFlag(MODULE)
-    sym.resetFlag(MODULE | FINAL | CASE)
-
- *  It's not relevant whether this example poses any issues: we must
- *  not tolerate these uncertainties.  If the flags are to move together
- *  then both setting and clearing have to be encapsulated.  If there
- *  is a useful and used distinction between the various permutations
- *  of on and off, then it must be documented.  It's the only way!
- */
-
+/** Comment deleted, see internal.HasFlags. */
 import Flags._
 
 /** Common code utilized by `Modifiers` (which carry the flags associated