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-8133 Fix regression with package objects, overloading

Regressed in f5c336d56, a refactoring of `typedIdent`. In that
commit, an (ostensibly) accidental change arrived, equivalent to:

    - val pre1  = if (qual == EmptyTree) NoPrefix else if (sym.isTopLevel) sym.owner.thisType else qual.tpe
    + val pre1  = if (sym.isTopLevel) sym.owner.thisType else if (qual == EmptyTree) NoPrefix else qual.tpe

Here, `qual` is a tree returned in the successful result of
`Context#lookup`.

This change itself looks innocuous (top level symbols can be prefixed
with a qualifier or not, right?), but it exposed us to a bug in
`makeAccessible`. It is responsible for rewriting, e.g,
`scala.List` to `scala.package.List`. It has a few cases, but one
of them relies relies on typechecking `Ident(nme.PACKAGE)`, and
hoping that it will bind to the right place. That's fraught with
danger, and breaks in the enclosed tests.

This commit binds that Ident symbolically, and in the process
factors a tiny bit of code in common with `TreeGen`. (More work
is still needed here!)

In the next commit, I'm going to revert the change to `pre1`. That
would have also fixed the regression, albeit symptomatically.
SI-8151 Remove -Yself-in-annots and associated implementation

This experimental option typechecked arguments of annotations
with an injected value in scope named `self`:

    @Foo(self.foo < 1)

This has been slated for removal [1] for some time.

This commit removes it in one fell swoop, without any attempt
at source compatibility with code that constructs or pattern
matches on AnnotatedType.

[1] https://groups.google.com/d/msg/scala-internals/VdZ5UJwQFGI/C6tZ493Yxx4J
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
Improve naming of ReadStdin

We don't need to say everything twice, methods are already prefixed
with “read”.
quasiquotes no longer evaluate debug logs when debug logging is off
fixes a typo in Types.scala
SI-8158 compiler hangs printing out fancy types

Apparently, even though the compiler has safeguards against infinite type
printouts, having a depth counter, we didn’t account for the cases when
printouts are both self-referential and self-multiplying.

For one, SI-8158 provides an example of such a type, which is a structural
type that refers to itself twice in return types of its methods. At first,
printing such a type would go deeper and deeper, but then it will hit
the depth limit and start multiply indefinitely.

This commit fixes this particular problem by recognizing self-references
as this.type’s and printing them out as such. The subsequent commit will
introduce a more general facility.
introduces failsafe against endless type printing

The parent commit works around a particular problem that led to a compiler
freeze in SI-8158, whereas this commit introduces a general solution -
a cache that tracks all types that we've recursed into during printing.

I can't immediately come up with an example of a type that would be caught
by this safety net, but unknown unknowns are the worst of them all, so why not
guard against them while we can.
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.
capitalizes “s” in tostring

As suggested by the reviewers, tostringXXX variables in TypeToStrings.scala
have been renamed to toStringXXX.
addresses pull request feedback
temporarily disables the toStringSubjects cache
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`.
SI-7445 ListMap.tail is returning wrong result

Reverted the commit that introduced the bug, and modified HashMap to no
longer assume that tail is O(1).

Review by @Ichoran, @soc
Merge pull request #3385 from xeno-by/ticket/8158

fixes some typos and types