Backports library changes related to SI-6566 from a419799

The idea of backporting this occured while developing the -source flag
for SI-8126 : withouth this the library breaks at refchecks for a
Scala compiler that checks type aliases variance.

This shoudl be BC and promote good hygiene.
[nomaster] Update MiMa and use new wildcard filter

scala.reflect.internal._ now gets a free pass from binary
compatibility checking.

Previously, we had to excrutiatingly exclude violations individually.
[nomaster] SI-8146 Fix non-deterministic <:< for deeply nested types

Backported from master. This is a squashed commmit comprising:

SI-8146 Pending test, diagnosis for bug in decidability of <:<

(cherry picked from commit 8beeef339ad65f3308ece6fb0440cdb31b1ad404)

SI-8146 Test cases for typechecking decidability

Taken from "On Decidability of Nominal Subtyping with Variance"
(Pierce, Kennedy), which was implemented in 152563b.

Part of the implementation (SubTypePair) will be changed in the
following commit to fix the non-deterministic errors typechecking
heavily nested types involving aliases or annotations.

(cherry picked from commit 2e28cf7f76c3d5fd0c2df4274f1af9acb42de699)

SI-8146 Fix non-deterministic <:< for deeply nested types

In the interests of keeping subtyping decidable [1], 152563b
added some bookkeeping to `isSubType` to detect cycles.

However, this was based on a hash set containing instances of
`SubTypePair`, and that class had inconsistencies between its
`hashCode` (in terms of `Type#hashCode`) and `equals`
(in terms of `=:=`).

This inconsistency can be seen in:

    scala> trait C { def apply: (Int @unchecked) }
    defined trait C

    scala> val intUnchecked = typeOf[C].decls.head.info.finalResultType
    intUnchecked: $r.intp.global.Type = Int @unchecked

    scala> val p1 = new SubTypePair(intUnchecked, intUnchecked)
    p1: $r.intp.global.SubTypePair = Int @unchecked <:<? Int @unchecked

    scala> val p2 = new SubTypePair(intUnchecked.withoutAnnotations, intUnchecked.withoutAnnotations)
    p2: $r.intp.global.SubTypePair = Int <:<? Int

    scala> p1 == p2
    res0: Boolean = true

    scala> p1.hashCode == p2.hashCode
    res1: Boolean = false

This commit switches to using `Type#==`, by way of the standard
case class equality.

The risk here is that you could find a subtyping computation that
progresses in such a manner that we don't detect the cycle. It would
need to produce an infinite stream of representations for types that
were `=:=` but not `==`. If that happened, we'd fail to terminate,
rather than judging the relationship as `false`.

[1] http://research.microsoft.com/pubs/64041/fool2007.pdf

(cherry picked from commit a09e143b7fd1c6b433386d45e9c5ae3548819b59)

Conflicts:
	src/reflect/scala/reflect/internal/tpe/TypeComparers.scala
	src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
Merge pull request #3367 from retronym/backport/3363

[nomaster]  Fix non-deterministic <:< for deeply nested types
Merge pull request #3359 from huitseeker/issue/VarianceAdaptations

[backport] Backports library changes related to SI-6566 from a419799
[nomaster] corrects an error in reify’s documentation
Merge pull request #3415 from xeno-by/topic/reify210x

[nomaster] corrects an error in reify’s documentation
SI-8205 [nomaster] backport test pos.lineContent

Verifies previous behavior.
Merge pull request #3430 from som-snytt/issue/8205-backport

SI-8205 [nomaster] backport test pos.lineContent
[backport] SI-7902 Fix spurious kind error due to an unitialized symbol

Tracked down this error:

    <none> is invariant, but type Y2 is declared covariant
    <none>'s bounds<notype> are stricter than type X2's declared bounds >: Nothing <: Any, <none>'s bounds<notype> are stricter than type Y2's declared bounds >: Nothing <: Any

to `Symbol#typeParams` returning `List(NoSymbol)` if the symbol
was not initialized.

This happends in the enclosed test for:

    // checkKindBoundsHK()
    hkArgs   = List(type M3)
    hkParams = List(type M2)

This commit forces the symbol of the higher-kinded type argument
before checking kind conformance.

A little backstory:

The `List(NoSymbol)` arises from:

    class PolyTypeCompleter... {
      // @M. If `owner` is an abstract type member, `typeParams` are all NoSymbol (see comment in `completerOf`),
      // otherwise, the non-skolemized (external) type parameter symbols
      override val typeParams = tparams map (_.symbol)

The variation that triggers this problem gets into the kind
conformance checks quite early on, during naming of:

    private[this] val x = ofType[InSeq]

The inferred type of which is forced during:

    def addDerivedTrees(typer: Typer, stat: Tree): List[Tree] = stat match {
      case vd @ ValDef(mods, name, tpt, rhs) if !noFinishGetterSetter(vd) =>
        // If we don't save the annotations, they seem to wander off.
        val annotations = stat.symbol.initialize.annotations

(cherry picked from commit 03a06e02483eaf442158339c2edd6bcfd99847a3)
Merge pull request #3491 from retronym/backport/7902

[backport] SI-7902 Fix spurious kind error due to an unitialized symbol
SI-8266 Amend advice for deprecated octal 042

Improve the advice for `f"\042"` to read:

```
use ${'"'} or a triple-quoted literal """with embedded " or \u0022""" instead.
```

as per the discussion on SI-6476.

Knuth says that Charles XII came close to introducing octal arithmetic to Sweden,
and Wikipedia doesn't deny it.

I imagine an alternative history in which octal literals are deprecated in Scala
but required by legislation in Akka. #octal-fan-fiction
[backport] no longer warns on calls to vampire macros

As eloquently elaborated and cleverly named by Travis Brown, macros
defined in structural types are useful:
http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/.

However, since such macros are on the intersection of a number of language
features, as usual, there are bugs.

This commit fixes an unwanted interaction of macros defined in structural
types with the scala.language.reflectiveCalls guard. Since macro calls
aren't going to be carried to runtime, there's no need to warn about them.
SI-8376 Fix overload resolution with Java varargs

When comparing specificity of two vararg `MethodTypes`, `isAsSpecific`
gets to:

```
  case mt @ MethodType(_, _) if bothAreVarargs =>
    checkIsApplicable(mt.paramTypes mapConserve repeatedToSingle)
```

The formal parameter type of a Java varargs parameter is represented
as `tq"${defintions.JavaRepeatedParamClass}[$elemTp]"`. For a Scala
repeated parameter, we instead use `defintions.RepeatedParamClass`.

`bothAreVarargs` detects `JavaRepeatedParamClass`, by virtue of:

```
def isRepeatedParamType(tp: Type)      = isScalaRepeatedParamType(tp) || isJavaRepeatedParamType(tp)
```

But, `repeatedToSingle` only considers `RepeatedParamClass`.

This bug was ostensibly masked in 2.10.3, but became apparent after
a not-quite-refactoring in 0fe56b9770. It would be good to pin that
change down to a particular line, but I haven't managed that yet.
SI-8376 Better type printing for Java varargs

`T*` rather than `<repeated>[T]`, as we alreday do for Scala repeated
parameters.
SI-8363 Disable -Ydelambdafy:method in constructor position

As @magarciaEPFL has done in his experimental optimizer [1], we can
avoid running into limitations of lambdalift (either `VerifyError`s,
ala SI-6666, or compiler crashes, such as this bug), by using the
old style of "inline" lambda translation when in a super- or self-
construtor call.

We might be able to get these working later on, but for now we
shouldn't block adoption of `-Ydelamndafy:method` for this corner
case.

[1] https://github.com/magarciaEPFL/scala/blob/GenRefactored99sZ/src/compiler/scala/tools/nsc/transform/UnCurry.scala#L227
SI-8366 make partial function and match trees disjoint

Previously one could match a partial function with match quasiquote:

    scala> val q"$scrutinee match { case ..$cases }" = q"{ case Foo => Bar
    }"
    scrutinee: universe.Tree = <empty>
    cases: List[universe.CaseDef] = List(case Foo => Bar)

This was quite annoying as it leaked encoding of partial functions as
Match trees with empty tree in place of scrutinee.

This commit make sure that matches and partial functions are disjoint
and don't match one another (while preserving original encoding under
the hood out of sight of the end user.)
Add more tests for partial functions
SI-8386 fixed
Fixes syntax error in unix runner.