SI-7622 Phase assembly is testable

Fixing hash on nodes makes fault detection deterministic,
which aids testing.

Error messages are shortened and .dot files are dumped
automatically on faults to guard against future flakiness.
SI-7622 -Xgenerate-phase-graph is an info option

-Xgenerate-phase-graph is comparable to -Xshow-phases.

The knowledge about what is an info-only option is refactored
to Settings, which also knows which group of options comprise
the optimiser set.
SI-7622 Phases are enabled or not

Refactor the calculation of the "phase chain" a bit.
In particular, initial and terminal phases are not special
except that they must be head and last.

When done, filter for enabled phases. At this commit,
nobody claims to be disabled.

Additional sanity support of phases settings.
SI-7622 -Xshow-phases can show disabled phases

With -Ydebug, -Xshow-phases will show phases that are skipped
or not enabled.

The code is slightly refactored, so the flags table will also benefit.
SI-7622 Plugins can be not enabled

Plugins can interrogate options and declare themselves not
enabled.  The plugin itself can return false from its init
if the options do not compute.  A plugin phase component
can declare itself not enabled, same as an internal phase.

No one exploits this facility at this commit.
SI-7622 Clean Up Phase Assembly

Let optimiser components and continuations plugin opt-out
when required flags are not set.

Wasted time on a whitespace error in check file, so let
--debug dump the processed check file and its diff.
SI-7622 Scaladoc and error message polish

Restores the verbiage "run right after".
Merge branch '2.10.2' into 2.10.3

Conflicts:
	src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
Merge pull request #2878 from JamesIry/2.10.3

Merge 2.10.2 into 2.10.3
SI-7269 Rework MapLike#retains to account for desugaring change

`MapLike#retains` contains a for-comprehension that relied on the strict
`filter` by its generator. You can't, in general, iterate a mutable map
and remove items in the same pass.

Here's the history of the desugaring of:

    def retain[A, B](thiz: mutable.Map[A, B])(p: (A, B) => Boolean): thiz.type = {
      thiz.foreach {
        case (k, v) =>
          if (p(k, v)) thiz -= k
      }

Before regression (c82ecabad6~1):

    thiz.filter(((check$ifrefutable$1) => check$ifrefutable$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => true
       case _ => false
    })).withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

After regression (c82ecabad6, which incorrectly assumed in the parser that
no filter is required for isInstanceOf[Tuple2])

    thiz.withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
      case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

After the reversion of c82ecabad6, v2.10.2
This is also after 365bb2b4e, which uses `withFilter` rather than `filter`.

    thiz.withFilter(((check$q$1) => check$ifrefutable$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => true
       case _ => false
    })).withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
      case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

This commit does the same as `SetLike#retains`, and converts the map to
an immutable list before the rest of the operation.
update typesafe.artifactory-online.com to private-repo
[nomaster] SI-7652 Bad tools fails loudly

A brief message is all that's required to
alleviate the look of consternation on the
face of your user.
[nomaster] SI-7652 REPL extended quest for tools

Javap tries harder and fails louder when
looking for tools.jar

This is a backport of the method as it
was first coded for partest.

If JAVA_HOME is wrong, it will either
fail with a message or succeed after
rooting about.

```
apm@mara:~/tmp/q$ JAVA_HOME=$JAVA7_HOME JAVACMD='/usr/lib/jvm/java-6-openjdk-amd64/bin/java' /home/apm/projects/snytt/build/pack/bin/scala
Welcome to Scala version 2.10.3-20130829-123337-59d6568daa (OpenJDK 64-Bit Server VM, Java 1.6.0_27).
Type in expressions to have them evaluated.
Type :help for more information.

scala> :javap
:javap [-lcsvp] [path1 path2 ...]

scala> :javap java.lang.Object
Failed: Could not load javap tool. Check that JAVA_HOME is correct.

apm@mara:~/tmp/q$ JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64/jre JAVACMD='/usr/lib/jvm/java-6-openjdk-amd64/bin/java' /home/apm/projects/snytt/build/pack/bin/scala
Welcome to Scala version 2.10.3-20130829-123337-59d6568daa (OpenJDK 64-Bit Server VM, Java 1.6.0_27).
Type in expressions to have them evaluated.
Type :help for more information.

scala>

scala> :javap
:javap [-lcsvp] [path1 path2 ...]

scala> :javap java.lang.Object
Compiled from "Object.java"
```
Change Scala license to unmodified 3-clause BSD.

No longer using the slightly reworded 3-clause BSD license.
This does not change the meaning of the license,
just aligns it with the standard wording.
SI-7801 Fix a nightmarish bug in Symbols#adaptInfos

The compiler-in-residence has always been a sketchy affair;
FSC and REPL offers a bounty of bugs that exploit the menagerie
of time-travel mechanisms in play for symbols' metadata (type, flags,
name and owner.) but are often cleverly masked by optimizations in
the compiler based on reference equality.

The latest: an innocuous change in Erasure:

  https://github.com/scala/scala/commit/d8b96bb8#commitcomment-3995163

means that some `ErasureMap`-s over `MethodType`-s are now true
identities (as `UnitTpe` is always the same object, whereas
`erasedTypeRef(UnitClass)` returns an different `TypeRef` each
time.)

This, in turn, enables `TypeMap#mapOver` to reuse
the existing enclosing type, and so on. On such subtleties hinge
further optimizations, such as whether or not a given phase's
`InfoTransformer` needs to add an entry in a symbols type history.

When the REPL (or FSC / Presentation Compiler) creates a new
`Run`, `Symbol#rawInfo` tries to adapt the entries in the type
history for the new run. For packages, this was taken to be a
no-op; each entry is marked as being valid in the new run and
no further action is taken. This logic lurks in `adaptInfos`.

But, when the namer enters a new symbol in a package, it
*mutates* the Scope of that package classes info `enteringTyper`.
So the later entries in the type history *must* be invalidated
and recomputed.

We have two choices for a fix:

 1) modify `Namers#enterInScope` to blow away the subsequent
    type history for the owning symbol after inserting the
    new member. Something like `owner.setInfo(owner.info)` would
    have the desired effect.
 2) Change `adaptInfos` to be more conservative when it comes
    to package classes, and retain only the oldest entry in the
    type history.

This commit goes for option 2.
Merge remote-tracking branch 'origin/2.10.x' into merge/2.10.x-to-2.10.3
SI-7814 Avoid init cycle between Predef, `package`, ScalaRuntime

Not every application will force these in a single thread; we
have to do our best to avoid cycles between them.

The enclosed test was failing every time before the change.

This commit breaks the cycle by avoiding computing `tupleNames`
in the constructor of `ScalaRuntime`. The new version has the
added benefit of including specialized tuple subclasses, which
is verified with a unit test for `isTuple`.

Are there more of these lurking? It seems likely. I'm more than
a little concerned about the way the `ControlThrowable` fires up
`scala.SystemProperties` to check whether or not to suppress
stack traces; there is already an ugly hack in place:

    object NoStackTrace {
      final def noSuppression = _noSuppression

      // two-stage init to make checkinit happy,
      // since sys.SystemProperties.noTraceSupression.value
      // calls back into NoStackTrace.noSuppression
      final private var _noSuppression = false
      _noSuppression = sys.SystemProperties.noTraceSupression.value
    }
SI-7814 Updates the instrumented version of ScalaRuntime.

Some tests for specialization use a modified version of
the standard library that count boxing, array lookups etc.

These sources are updated manually with the script:

    % test/instrumented/mkinstrumented.sh build

Looks that that wasn't done for a while, though.

This commit brings it up to date, and adjusts a few braces in
ScalaRuntime.scala so the patch srt.scala (used by that script)
is shorter.

We should really avoid checking in the products of that script and
run it as part of the build, or, better, use the bytecode
instrumentation framework instead of a modified standard library.
But I have to leave that for another day.
SI-7818 Cast our way out of extended existential angst

`substituteSymbols` is not sophisticated enough to
operate on `TypeSkolem`-s which are based on one of the
"from" symbols.

The pertinant usage of `substituteSymbols` for this bug in
in `Extender`. Recapping on that transform:

    // orig
    class C[T](...) extends AnyVal { def foo[U] = <rhs> }

    // transform
    class C[T] extends AnyVal { ... }
    object C  { def foo$extension[T', U'] = <rhs'> }

Where `<rhs'>` has been subtituted with, among other things,
`[T, U] ~> [T', U']`.

In this case our expected type contains a new type parameter
(of the extension method), whereas the type of the RHS contains
an existential skolem still pinned to the corresponding class type
parameter.

    tree.tpe         = Observable1#7037[_$1#12344]
    <_$1#12344>.info =  <: T#7040
    pt               = Observable1#7037[T#15644]

The limitation of substution is lamented in the comments
of `adaptMismatchedSkolems`, which faces the harder version of
the issue where the skolems are in the expected type.

But, we're in the "easy" case with the skolems in the tree's type;
we can cast our way out of the problem.

See also f335e447 / ed915c54.
SI-7815 Dealias before deeming method type as dependent

To enable eta-expansion of method types seen from a prefix that
renders the result type as independent from the parameter symbols.

The enclosed test shows that we dealias types before checking
dependence, and that we do this deeply (e.g. type arguments are
also dealised.)

An existing test, neg/error_dependentMethodTpeConversionToFunction,
confirms that bona-fide dependent methods are still prohibited from
eta expansion.