Merge pull request #3391 from xeno-by/ticket/8131

SI-8131 fixes residual race condition in runtime reflection
SI-8092 Review cleanup, no qq

No crazyquoting. Use global.abort on total fail.

Remove unnecessary usage of varargs Apply, per review.
SI-8237 Avoid cyclic constraints when inferring hk type args

An `AppliedTypeVars` spawned from `HKTypeVar#applyArgs`
(necessarily) shares the same `TypeConstraints`.

But, we can have multiple ATVs based on a single HKTV floating
around during inference, and they can appear on both sides
of type relations. An example of this is traced out in
the enclosed test.

This commit avoids registering upper/lower bound constraints
when this is detected.

In the enclosed test, we end up with an empty set of constraints
for `?E`, which results in inference of Nothing, which is what
we expect.

I have also improved the printing of ATVs (to include the args)
and sharpened the log message when `solve` leaves type variables
instantiated to `NoType`, rather than some other type that doesn't
conform to the bounds. Both of these changes helped me to get
to the bottom of this ticket. The improved `ATV#toString` shows
up in some updated checkfiles.

The reported test has quite a checkered history:

  - in 2.10.0 it worked, but more by good luck than good planning
  - after the fix for SI-7226 / 221f52757aa6, it started crashing
  - from 3bd897ba0054f (a merge from 2.10.x just before 2.11.0-M1)
    we started getting a type inference failure, rather than a crash.
    "no type parameters for method exists [...] because cyclic
    instantiation".
  - It still crashes in `isGround` in 2.10.3.
[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 #3420 from som-snytt/issue/8092-f-parsing

SI-8092 More verify for f-interpolator
SI-8202 bug compatibility with SI-8211 for quasiquotes
Move placeholder construction logic into Placeholders

Previously construction logic used to be in Parsers and deconstruction in
Placeholders making it easy to forget one if you change the other.
Move null check case higher to avoid NPE

Also use sym.isErrorneous instead of manual name check.
Improve support for patterns in vals

This commits adds construction-only support for splicing patterns into
vals (a.k.a. PatDef). Due to non-locality of the desugaring it would
have been quite expensive to support deconstruction as the only way to
do it with current trees is to perform implodePatDefs transformation on
every single tree.
SI-8154 AnyRefMap iterates its way to ((null, null))

Changed logic to prevent mutation between hasNext and next from delivering invalid results.

Also fixed superscripts in scaladoc.
SI-6736 Range.contains is wrong

Removed once-used private method that was calculating ranges in error and corrected the contains method (plus improved performance).
Merge pull request #3491 from retronym/backport/7902

[backport] SI-7902 Fix spurious kind error due to an unitialized symbol
Merge pull request #3485 from xeno-by/topic/reset-all-attrs

kills resetAllAttrs
changes the order of whitebox typechecks. yes, again.

My first attempt at SI-6992 was about having whitebox expansions first
typecheck against outerPt and only then verify that the result is compatible
with innerPt.

That was a nice try, but soon after it went live in 2.11.0-M8, we've got
multiple reports with problems - both shapeless and then in a week specs2
started having issues with their whitebox macros.

In shapeless, typecheck against outerPt screwed up type inference, which
was more or less fixable by explicit type annotations, so I decided to
wait a bit before jumping to conclusions.

However, in specs2 the problem was more insidious. After being typechecked
against outerPt, expansions were being implicitly converted to a type
that became incompatible with innerPt. This revealed a fatal flaw of the
implemented approach - if allowed to typecheck against outerPt first,
whitebox macros could never be robust.

Now realizing that "outerPt > innerPt" doesn't work, I nevertheless wasn't
looking forward to rolling that back to "innerPt > outerPt", because that
would revive SI-6992 and SI-8048 that are highly unintuitive, especially
the latter one.

Therefore, this commit combines the permissiveness of "... > innerPt"
approaches with the robustness of "innerPt > outerPt", introducing
"WildcardType > innerPt > outerPt".
Reasonable Range operations consistently work when overfull.

Operations are reasonable when they don't require indexing or conversion into a collection.  These include head, tail, init, last, drop, take, dropWhile, takeWhile, dropRight, takeRight, span.

Tests added also to verify the new behavior.
Optimization: use AnyRef map for Namer -> Typer tree handoff

And uses a map per-compilation unit, rather than one per Typer.

One small change required: we now need to clear this map in the
the interactive compiler which reuses compilation units, rather
than in the call to `Typer#reset`.
Optimation: use AnyRefMap in GenASM javaName caches

These are a hotspot in the backend.
SI-3452 Correct Java generic signatures for mixins, static forwarders

[Parts of this patch and some of the commentary are from @paulp]

This took me so long to figure out I can't even tell you. Partly because
there were two different bugs, one which only arose for trait forwarders
and one for mirror class forwarders, and every time I'd make one set
of tests work another set would start failing. The runtime failures
associated with these bugs were fairly well hidden because you usually
have to go through java to encounter them: scala doesn't pay that much
attention to generic signatures, so they can be wrong and scala might still
generate correct code. But java is not so lucky.

Bug #1)

During mixin composition, classes which extend traits receive forwarders
to the implementations. An attempt was made to give these the correct
info (in method "cloneBeforeErasure") but it was prone to giving
the wrong answer, because: the key attribute which the forwarder
must capture is what the underlying method will erase to *where the
implementation is*, not how it appears to the class which contains it.
That means the signature of the forwarder must be no more precise than
the signature of the inherited implementation unless additional measures
will be taken.

This subtle difference will put on an unsubtle show for you in test
run/t3452.scala.

    trait C[T]
    trait Search[M] { def search(input: M): C[Int] = null }
    object StringSearch extends Search[String] { }
    StringSearch.search("test");  // java
    // java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC;

The principled thing to do here would be to create a pair of
methods in the host class: a mixin forwarder with the erased
signature `(String)C[Int]`, and a bridge method with the same
erased signature as the trait interface facet.

But, this turns out to be pretty hard to retrofit onto the
current setup of Mixin and Erasure, mostly due to the fact
that mixin happens after erasure which has already taken
care of bridging.

For a future, release, we should try to move all bridging
after mixin, and pursue this approach. But for now, what can
we do about `LinkageError`s for Java clients?

This commit simply checks if the pre-erasure method signature
that we generate for the trait forward erases identically to
that of the interface method. If so, we can be precise. If not,
we emit the erased signature as the generic signature.

Bug #2) The same principle is at work, at a different location.
During genjvm, objects without declared companion classes
are given static forwarders in the corresponding class, e.g.

    object Foo { def bar = 5 }

which creates these classes (taking minor liberties):

    class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 }
    class Foo  { static def bar = Foo$.MODULE$.bar }

In generating these, genjvm circumvented the usual process whereby one
creates a symbol and gives it an info, preferring to target the bytecode
directly. However generic signatures are calculated from symbol info
(in this case reusing the info from the module class.) Lacking even the
attempt which was being made in mixin to "clone before erasure", we
would have runtime failures of this kind:

    abstract class Foo {
      type T
      def f(x: T): List[T] = List()
    }
    object Bar extends Foo { type T = String }
    Bar.f("");    // java
    // java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List;

Before/after this commit:

    <   signature                                     f  (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>;
    ---
    >   signature                                     f  (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>;

This takes the warning count for compiling collections under
`-Ycheck:jvm` from 1521 to 26.
SI-7374 Test cases for fixed Java interop problem

Our generic signatures now match the erasure, so no
more nasty linkage errors.
Merge pull request #3371 from Ichoran/issue/8154

 AnyRefMap iterates its way to ((null, null))