SI-8143 Regressions with override checks, private members

These regressed in e609f1f20b, which excluded all private methods from
overriding checks. We should only exclude private[this] members on the
low end of a pair, as was done before that commit, and, we must also
exclude private members on the high side.

Why? Warning: reverse engineered intuition follows.

We need to report an error when if a private method in a subclass
has matches a less-private method in the super class and report an
error, lest the user be fooled into thinking it might be invoked
virtually. On the other hand, adding a private method to a super
class shouldn't invalidate the choice names of public members in
its superclasses.

I've removed the test case added by that commit and will lodge a
reworked version of it that Paul provided as a new issue. That shows
a bug with qualified private + inheritance.

In addition, the expectation of `neg/accesses.check` is reverted
to its 2.10.3 version, which I believe is correct. When it was
changed in e609f1f20b it sprouted a variation, `neg/accesses-2`,
which has now changed behaviour. The intent of that test will
be captured in the aforementioned issue covering qualified private
inheritance.
SI-6844 restrict splicing in parameter position

Previously were a bit too permissive on how splicing in function
parameter position worked. This made confusing things like
possible:

   val x = TermName(“x”)
   q”def foo($x)”

Now you can either splice trees in that position (ValDefs) or
you have to provide type if you splice a name.
SI-8076 improve support for implicit argument list

This adds support for construction and deconstruction
of implicit argument list which was originally suggested
by @cvogt.

1. Splicing vale into implicit argument list automatically
   adds implicit flag to them:

     val x = q"val x: Int"
     q"def foo(implicit $x)"
     // <=> q"def foo(implicit x: Int)"

2. One might extract implicit argument list separately from
   other argument lists:

     val q”def foo(...$argss)(implicit ..$impl)" =
       q"def foo(implicit x: Int)
     // argss is Nil, impl contains valdef for x

   But this doesn't require you to always extract it separatly:

     val q”def foo(...$argss)" =
       q"def foo(implicit x: Int)
     // argss contains valdef for x
a note about Symbol.typeSignature

No changes to behavior, just documenting internal workings of reflection
a bit more thoroughly, one step at a time.
Revert "synchronizes pendingVolatiles"

This reverts commit 000c18a8fac60065747652368dadcd7850532f3f,
because Symbol.isStable is independent from Type.isVolatile
since fada1ef6b315326ac0329d9e78951cfc95ad0eb0.
FromJavaClassCompleter is now flag-agnostic

A minor evolution of the notion of completion + also a small performance
optimization.
SI-8134 SI-5954 Fix companions in package object under separate comp.

The tests cases enclosed exhibited two failures modes under
separate compilation.

  1. When a synthetic companion object for a case- or implicit-class
     defined in a package object is called for,
     `Namer#ensureCompanionObject` is used to check for an explicitly
     defined companion before decided to create a synthetic one.
     This lookup of an existing companion symbol by `companionObjectOf`
     would locate a symbol backed by a class file which was in the
     scope of the enclosing package class. Furthermore, because the
     owner of that symbol is the package object class that has now
     been noted as corresponding to a source file in the current
     run, the class-file backed module symbol is *also* deemed to
     be from the current run. (This logic is in `Run#compiles`.)

     Thinking the companion module already existed, no synthetic
     module was created, which would lead to a crash in extension
     methods, which needs to add methods to it.

  2. In cases when the code explicitly contains the companion pair,
     we still ran into problems in the backend whereby the class-file
     based and source-file based symbols for the module ended up in
     the same scope (of the package class). This tripped an assertion
     in `Symbol#companionModule`.

We get into these problems because of the eager manner in which
class-file based package object are opened in `openPackageModule`.
The members of the module are copied into the scope of the enclosing
package:

    scala> ScalaPackage.info.member(nme.List)
    res0: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462

    scala> ScalaPackage.info.member(nme.PACKAGE).info.member(nme.List)
    res1: $r#59116.intp#45094.global#28436.Symbol#29451 = value List#2462

This seems to require a two-pronged defense:

  1. When we attach a pre-existing symbol for a package object symbol
     to the tree of its new source, unlink the "forwarder" symbols
     (its decls from the enclosing
     package class.

  2. In `Flatten`, in the spirit of `replaceSymbolInCurrentScope`,
     remove static member modules from the scope of the enclosing
     package object (aka `exitingFlatten(nestedModule.owner)`).

This commit also removes the warnings about defining companions
in package objects and converts those neg tests to pos (with
-Xfatal-warnings to prove they are warning free.)

Defining nested classes/objects in package objects still has
a drawback: you can't shift a class from the package to the
package object, or vice versa, in a binary compatible manner,
because of the `package$` prefix on the flattened name of
nested classes. For this reason, the `-Xlint` warning about
this remains. This issue is tracked as SI-4344.

However, if one heeds this warning and incrementatlly recompiles,
we no longer need to run into a DoubleDefinition error (which
was dressed up with a more specific diagnostic in SI-5760.)
The neg test case for that bug has been converted to a pos.
SI-5954 Invalidate TypeRef cache when opening package object

I noticed that the pos/5954d was tripping a println "assertion".
This stemmed from an inconsistency between
`TypeRef#{parents, baseTypeSeq}` for a package objects compiled
from source that also has a class file from a previous compilation
run.

I've elevated the println to a devWarning, and changed
`updatePosFlags`, the home of this evil symbol overwriting,
to invalidate the caches in the symbols info. Yuck.

I believe that this symptom is peculiar to package objects because
of the way that the completer for packages calls `parents` during
the Namer phase for package objects, before we switch the symbol
to represent the package-object-from-source. But it seems prudent
to defensively invalidate the caches for any symbol that finds its
way into `updatePosFlags`.
removes non-determinism in reflection-sync-potpourri

Depending on the environment in which the test is run, s1 can be either
“String” or “java.lang.String”. This is one of the known non-deterministic
behaviors of our reflection, caused by prefix stripping only working for
packages defined in the root mirror. Until we fix this, I suggest we make
the test more lenient.
SI-8131 fixes residual race condition in runtime reflection

Apparently some completers can call setInfo while they’re not yet done,
which resets the LOCKED flag, and makes anything that uses LOCKED to
track completion unreliable. Unfortunately, that’s exactly the mechanism
that was used by runtime reflection to elide locking for symbols that are
known to be initialized.

This commit fixes the problematic lock elision strategy by introducing
an explicit communication channel between SynchronizedSymbol’s and their
completers. Now instead of trying hard to infer whether it’s already
initialized or not, every symbol gets a volatile field that can be queried
to provide necessary information.
SI-5954 Add a TODO comment with an idea for future work

As the prophet once said:

  "'Tis better to never do at all than to have do and undo"

Let's try that in 2.12.
Scaladoc jars should go to /api.
Remove cruft from pom.

My understanding is distributionManagement is only needed to configure
maven locally for publishing. Since we do that it ant, getting rid of it.
SI-8170 Fix regression in TypeRef#transform w. PolyTypes

Regressed in SI-8046 / edc9edb7, by my hand.

At the time, I noticed the problem: transform wasn't accounting
for the potential Poly-Type-ness of its argument, and this would
lead to under-substituted types. The commit comment of edc9edb7
shows an example.

But the remedy wasn't the right one. The root problem is
that a TypeMap over a PolyType can return one with cloned
type parameter symbols, which means we've lose the ability
to substitute the type arguments into the result.

This commit detects up front whether the type-under-transform
is a PolyType with the current TypeRef's type parameters, and
just runs the `asSeenFrom` over its result type.
Tag synthetic unit with attachment

This makes it easy to differentiate unit inserted by a compiler vs unit
written by the user. Useful for quasiquotes and pretty printing.

Additionally SyntacticBlock extractor is changed to treat EmptyTree as
zero-element block.
Refactor reification of high-cardinality holes

New approach makes iterated function much more clear through aggressive
code reuse, recursion and large descriptive comment on top of it.
SI-7275 allow flattening of blocks with ..$

This commit extends current splicing rules to allow flattening of
trees into other trees.

Without such support it is impossible to correctly create vals with
patterns and use it in other location as they could expand into
multiple-statement blocks:

    scala> q"val (a, b) = (1, 2)"
    res0: reflect.runtime.universe.Tree =
    {
      <synthetic> <artifact> private[this] val x$1 = scala.Tuple2(1, 2):
    @scala.unchecked match {
        case scala.Tuple2((a @ _), (b @ _)) => scala.Tuple2(a, b)
      };
      val a = x$1._1;
      val b = x$1._2;
      ()
    }

    scala> q"..$res0; println(a + b)"
    res1: reflect.runtime.universe.Tree =
    {
      <synthetic> <artifact> private[this] val x$1 = scala.Tuple2(1, 2):
    @scala.unchecked match {
        case scala.Tuple2((a @ _), (b @ _)) => scala.Tuple2(a, b)
      };
      val a = x$1._1;
      val b = x$1._2;
      println(a.$plus(b))
    }
Address pull request feedback
SI-7570 top-level codegen for toolboxes

Provides a way to inject top-level classes, traits and modules into
toolbox universes.

Previously that was impossible, because compile and eval both wrap their
arguments into an enclosing method of a synthetic module, which makes it
impossible to later on refer to any definitions from the outside.
Reify all blocks as syntactic blocks

Previous version of the pattern wasn't precise enough due to the
fact that synthetic units are now erased by syntactic block and
this could cause incorrect reification for cases like:

   val x = { val y = 1 }

Here syntactic block would extract one element but we still need to
reify it through syntactic block endpoint. So we can't filter based
on the number of elements extracted but rather filter on type of a
tree.