SI-7369 Avoid spurious unreachable warnings in patterns

Unreachability analysis draws on the enumerated domain of types
(e.g sealed subclasses + null, or true/false), and also looks at all
stable identifier patterns tested for equality against the same 'slot'
in a pattern.

It was drawing the wrong conclusions about stable identifier patterns.
Unlike the domain constants, two such values may hold the same value,
so we can't assume that matching X precludes matching Y in the same
slot in a subsequent case.

For example:

    val X: Boolean = true; val Y: Boolean = true
    def m1(t1: Tuple1[Boolean]) = t1 match {
      case Tuple1(true) =>
      case Tuple1(false) =>
      case Tuple1(false) => // correctly unreachable
    }
    def m2(t1: Tuple1[Boolean]) = t1 match {
      case Tuple1(X) =>
      case Tuple1(Y) => // spurious unreachable warning
    }

    //
    // Before
    //
    reachability, vars:
    V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1
    V1: (Boolean,) ::= null | ... // = x1
    equality axioms:
      V2=true#4  \/ V2=false#5  /\
     -V2=false#5 \/  -V2=Y#3    /\
     -V2=false#5 \/  -V2=X#2    /\
     -V2=false#5 \/ -V2=true#4  /\
       -V2=Y#3   \/  -V2=X#2    /\
       -V2=Y#3   \/ -V2=true#4  /\
       -V2=X#2   \/ -V2=true#4

    //
    // After
    //
    reachability, vars:
    V2: Boolean ::= true | false// Set(false, Y, X, true) // = x1._1
    V1: (Boolean,) ::= null | ... // = x1
    equality axioms:
      V2=true#4  \/ V2=false#5  /\
     -V2=false#5 \/ -V2=true#4
Warn on selection of vals from DelayedInit subclasses.

Which are likely to yield null, if the program didn't start.

This is a common source of confusion for people new to
the language, as was seen during the Coursera course.

The test case shows that the usage pattern within Specs2
won't generate these warnings.
SI-6532 emit debug info in compiled java.

Our handful of java source files weren't being compiled
with line numbers, sourcefile, and other debugger aids.
I don't really know how to test this so I'll enclose an
excerpt of the bytecode diff of scala.runtime.IntRef to show
that this change results in debug information.

  2,3c2,4
  >   Compiled from "IntRef.java"
  4a6
  >   SourceFile: "IntRef.java"
  53a62,67
  >       LineNumberTable:
  >         line 18: 0
  >       LocalVariableTable:
  >         Start  Length  Slot  Name   Signature
  >                0      10     0  this   Lscala/runtime/IntRef;
  >                0      10     1  elem   I
  62a77,81
  >       LineNumberTable:
  >         line 19: 0
  >       LocalVariableTable:
  >         Start  Length  Slot  Name   Signature
  >                0       8     0  this   Lscala/runtime/IntRef;
use relative symlink in distpack

To simplify building a release on jenkins, we run distpack-opt in one job,
store the `dists/` directory in a tar ball, archive that artifact and
copy it to the downstream jobs that package on windows and unix.

To make the tarball portable between machines, it must not use absolute symlinks.
SI-6771 Alias awareness for checkableType in match analysis.

Failure to dealias the type of the scrutinee led the pattern
matcher to incorrectly reason about the type test in:

   type Id[X] = X; (null: Id[Option[Int]]) match { case Some(_) => }

Before, `checkableType` returned `Id[?]`, now it returns `Some[?]`.
[nomaster] SI-5353 prohibits Array()

TODO: I'm about to fix SI-5923, and that fix is going to uncover SI-5353
(see more information here: https://github.com/scala/scala/pull/2464).

Since the fix to SI-5353 is going to bring binary incompatibilities,
we cannot include it into 2.10.x, but we want to fix SI-5923 in 2.10.2.

Therefore we decided to emulate the portion of SI-5923 that used to mask
SI-5353. That's only a temporary hack targeted at 2.10.x. There's no
reason for this code to be merged into master.
[nomaster] SI-5923 instantiate targs in deferred macro applications

Amazingly enough, the fix for the "macro not expanded" problem was super
easy. (And I remember spending a day or two trying to find a quick fix
somewhen around Scala Days 2012!)

The problem was in the implementation of the macro expansion trigger,
which was buried in a chain of if-elif-elif in `adapt`. This meant that macro
expansion was mutually exclusive with a lot of important adaptations, e.g.
with `instantiate`.

More precisely, if an expandee contains an undetparam, its expansion
should be delayed until all its undetparams are inferred and then retried
later. Sometimes such inference can only happen upon a call to instantiate
in one of the elif's coming after the macro expansion elif. However this
elif would never be called for expandees, because control flow would always
enter the macro expansion branch preceding the inference branch.

Therefore `macroExpand` now takes the matters in its own hands,
calling `instantiate` if the expansion has been delayed and we're not in
POLYmode (see a detailed explanation in a comment to `macroExpand`).

Consequences of this fix are vast. First of all, we can get rid of the
"type parameter must be specified" hack. Secondly and most importantly,
we can now remove the `materializeImplicit` method from Implicits and
rely on implicit macros to materialize tags for us. (This is a tricky
change, and I'll do it later after we merge as much of my pending work
as possible). Finally, we learn that the current scheme of interaction
between macros, type inference and implicits is, in principle, sound!

NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013:
https://github.com/scala/scala/commit/fe60284769.

The original fix had an unfortunate error, as described on scala-internals:
https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had
to refine the approach here.

This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
[nomaster] macroExpandAll is now triggered in all invocations of typed

macroExpandAll is the key player in the mechanism of expanding macros after
their type arguments have been inferred. (Macro applications that contain
yet uninferred type arguments don't get expanded and are delayed until
the targs are inferred. Therefore later on we need to trigger those delayed
expansions manually, which is done by macroExpandAll).

Previously macroExpandAll was only called from a few selected places in
the typechecker, but that's quite risky, since typer evolves, and who knows
when this scheme breaks.

To make things more robust, I'm now calling macroExpandAll in the epilogue
of every single call to `typed`. Don't worry - this shouldn't impose
noticeable performance penalties, since the call is guarded by a branch
upon a plain boolean field.

NOTE: This patch is a second take on fixing implicit macros, with the first
one being a backport from macro paradise merged into master in January 2013:
https://github.com/scala/scala/commit/fe60284769.

The original fix had an unfortunate error, as described on scala-internals:
https://groups.google.com/forum/#!msg/scala-internals/7pA9CiiD3u8, so I had
to refine the approach here.

This means that it's not possible to directly merge this commit into master,
so I'm marking it as [nomaster] and will submit a separate pull request
targetting master later on.
[nomaster] SI-5923 a simple alternative to onInfer

This fix provides implicit macros with an ability to affect type inference
in a more or less sane manner. That's crucial for materialization of
multi-parametric type class instances (e.g. Iso's from shapeless).
Details of the technique can be found in comments.

The changes introduced here are good from the conceptual point of view,
but are sub-standard as far as clarity and cleanliness are concerned.
As the latest advances in implicit macrology show, there's no need for
an elaborate mechanism of keeping track of undetparams in Macros.scala,
therefore we should really clean that stuff out. However, this is 2.10.x,
and I want to minimize the surface of code changes in order to make sure
I don't break anything.

Having said all that, I'd like to note that this commit is only targeted
at 2.10.x. There's no reason for it to be merged into master.