SI-8871 Fix specialization under REPL / FSC

The transformation of applications to specialized methods
relies on the owner of said method having had the specialization
info transform run which stashes a bunch of related data into
per-run caches such as `SpecializeTypes#{typeEnv}`.

Recently, we found that per-run caches didn't quite live up
to there name, and in fact weren't being cleaned up before
a new run. This was remedied in 00e11ff.

However, no good deed goes unpunished, and this led to a
regression in specialization in the REPL and FSC.

This commit makes two changes:

  - change the specialization info tranformer to no longer
    directly enter specialized methods into the `info` of whatever
    the current phase happens to be. This stops them showing up
    `enteringTyper` of the following run.
  - change `adaptInfos` to simply discard all but the oldest
    entry in the type history when bringing a symbol from one
    run into the next. This generalizes the approach taken to
    fix SI-7801. The specialization info transformer will now
    execute in each run, and repopulate `typeEnv` and friends.

I see that we have a seemingly related bandaid for this sort
of problem since 08505bd4ec. In a followup, I'll try to revert
that.
SI-5583 Remove the workaround for specialization bug

08505bd added a workaround for an undiagnosed interaction
between resident compilation and specialzation. This is no
longer needed after the previous commit.
SI-6613 Make Java enums work in FSC / REPL

We needed to hop from the enum's owner to its companion
module in an early phase of the compiler.

The enclosed test used to fail when this lookup returned
NoSymbol on the second run of the resident compiler when
triggered from `MixinTransformer`: the lookup didn't work
after the flatten info transform. This is related to the
fact that module classes are flattened into the enclosing
package, but module accessors remain in the enclosing class.
Optimize tail calls to avoid findMember calls

Cache the member symbols for `Boolean.{||, &&}` per-run, rather
than look them up repeatedly.

Based on profiling the tail calls phase in the program below, which
was distilled by @rmacleod2 from the code generated by macros in
https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper

Wall clock time went from 12s to 6.5s.

```scala
object Test {
    def a(): Option[String] = Some("a")

    def main(args: Array[String]) {
        a() match {
            case Some(b1) =>
        a() match {
            case Some(b2) =>
        a() match {
            case Some(b3) =>
        a() match {
            case Some(b4) =>
        a() match {
            case Some(b5) =>
        a() match {
            case Some(b6) =>
        a() match {
            case Some(b7) =>
        a() match {
            case Some(b8) =>
        a() match {
            case Some(b9) =>
        a() match {
            case Some(b10) =>
        a() match {
            case Some(b11) =>
        a() match {
            case Some(b12) =>
        a() match {
            case Some(b13) =>
        a() match {
            case Some(b14) =>
        a() match {
            case Some(b15) =>
        a() match {
            case Some(b16) =>
        a() match {
            case Some(b17) =>
        a() match {
            case Some(b18) =>
        a() match {
            case Some(b19) =>
        a() match {
            case Some(b20) =>
                println("yay")
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
    }
}
```
Avoid needlessly deep chains of ClonedTailContext

I believe ClonedTailContext was added to avoid the need to
mutate the Boolean `ctx.tailPos`. All other calls are forwarded
to a delegate context.

This commit tries to find a delegate context with the right
value of `tailPos` to reuse that, rather than creating a
wrapper each time we need to flip that bit.
Wider use of mapConserve and the like in TailCalls

Save the Trees!

When a subtransform is an identity, we must
strive to return the identical tree to enable the lazy part of
LazyTreeCopier. If we get this wrong in a leaf, all parents are
wastefully copied.
SI-8893 Restore linear perf in TailCalls with nested matches

Compilation perfomance of the enclosed test regressed when the
new pattern matcher was introduced, specifically when the tail
call elimination phase was made aware of its tree shapes in cd3d34203.

The code added in that commit detects an application to a tail label
in order to treat recursive calls in the argument as in tail position.

If the transform of that argument makes no change, it falls
back to `rewriteApply`, which transforms the argument again
(although this time on a non-tail-position context.)

This commit avoids the second transform by introducing a flag
to `rewriteApply` to mark the arguments are pre-transformed.

I don't yet see how that fixes the exponential performance, as
on the surface it seems like a constant factor improvement.
But the numbers don't lie, and we can now compile the test
case in seconds, rather than before when it was running for
> 10 minutes.

This test case was based on a code pattern generated by the Avro
serializer macro in:

  https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper

The exponential performance in that context is visualed here:

  https://twitter.com/dridus/status/519544110173007872

Thanks for @rmacleod2 for minimizing the problem.
Avoid wasteful array creation in backend

The iteration is only needed to side effect on `instructionList`
and `code.touched`. This commit uses an iterator and `foreach`,
rather than creating throwaway Arrays.

    % time (for f in {1..200}; do echo test/files/pos/t8893.scala; done | qscalac -Xresident)

    Before: 30s
    After : 21s
SI-3439 Fix use of implicit constructor params in super call

When typechecking the primary constructor body, the symbols of
constructor parameters of a class are owned by the class's owner.
This is done make scoping work; you shouldn't be able to refer to
class members in that position.

However, other parts of the compiler weren't so happy about
this arrangement. The enclosed test case shows that our
checks for invalid, top-level implicits was spuriously triggered,
and implicit search itself would fail.

Furthermore, we had to hack `Run#compiles` to special case
top-level early-initialized symbols. See SI-7264 / 86e6e9290.

This commit:

  - introduces an intermediate local dummy term symbol which
    will act as the owner for constructor parameters and early
    initialized members
  - adds this to the `Run#symSource` map if it is top level
  - simplifies `Run#compiles` accordingly
  - tests this all in a top-level class, and one nested in
    another class.
SI-5454 Test case for another ticket fixed by the previous commit
SI-8910 BitSet sometimes uses exponential memory.

Because of an off-by-one error in scala.collection.mutable.BitSet, where a
function (ensureCapacity) is passed a list length instead of an index, when
^=, &=, |=, or &~= are passed BitSets with the same internal capacity as the
set the method is being invoked on, the size of the first BitSet is needlessly
doubled.

This patch simply changes the ensureCapacity calls to pass the last index of
the list, instead of the raw length. In addition, add documentation to
ensureCapacity to try and stop something similar from happening in the future.
fix typo. s/represenation/representation
SI-4950 Add tests, looks like it has been fixed earlier
SI-8875 showCode should print all class constructor modifiers.

showCode used to print nothing when the only modifier was a change in
visibility scope (i.e. no flags but privateWithin is set).
SI-8934 Fix whitebox extractor macros in the pres. compiler

The code that "aligns" patterns and extractors assumes that it can
look at the type of the unapply method to figure the arity of the
extractor.

However, the result type of a whitebox macro does not tell the
whole story, only after expanding an application of that macro do
we know the result type.

During regular compilation, this isn't a problem, as the macro
application is expanded to a call to a synthetic unapply:

    {
      class anon$1 {
        def unapply(tree: Any): Option[(Tree, List[Treed])]
      }
      new anon$1
    }.unapply(<unapply selector>)

In the presentation compiler, however, we now use
`-Ymacro-expand:discard`, which expands macros only to compute
the type of the application (and to allow the macro to issue
warnings/errors). The original application is retained in the
typechecked tree, modified only by attributing the potentially-sharper
type taken from the expanded macro.

This was done to improve hyperlinking support in the IDE.

This commit passes `sel.tpe` (which is the type computed by the
macro expansion) to `unapplyMethodTypes`, rather than using
the `finalResultType` of the unapply method.

This is tested with a presentation compiler test (which closely
mimics the reported bug), and with a pos test that also exercises
`-Ymacro-expand:discard`. Prior to this patch, they used to fail with:

    too many patterns for trait api: expected 1, found 2
Make global-showdef a DirectTest

The test test/files/run/global-showdef.scala was outputting
to the cwd instead of the test output dir.

Good behavior is now inherited from DirectTest.

Test frameworks, of any ilk or capability, rock.
Reduce compiles for global-showdef test

You can only show one class or object at a time,
but we can show one of each to reduce the compilations
for this test.

It seems the original issue happened because the test
started to create class files after SI-8217.

So, also stop compile after typer, because why stress the kitteh.
SI-8941 Idempotent presentation compilation of implicit classes

When we name an implicit class, `enterImplicitWrapper` is called,
which enters the symbol for the factory method into the
owning scope. The tree defining this factory method is stowed into
`unit.synthetics`, from whence it will be retrieved and incorporated
into the enclosing tree during typechecking (`addDerivedTrees`).
The entry in `unit.synthetics` is removed at that point.

However, in the presentation compiler, we can typecheck a unit
more than once in a single run. For example, if, as happens
in the enclosed test, a call to ask for a type at a given
position interrupts type checking of the entire unit, we
can get into a situation whereby the first type checking
invocation has consumed the entry from `unit.synthetics`,
and the second will crash when it can't find an entry.

Similar problems have been solved in the past in
`enterExistingSym` in the presentation compiler. This method
is called when the namer encounters a tree that already has
a symbol attached. See 0b78a0196 / 148736c3df.

This commit takes a two pronged approach.

First, `enterExistingSym` is extended to handle implicit classes.
Any previous factory method in the owning scope is removed, and
`enterImplicitWrapper` is called to place a new tree for the factory
into `unit.synthetics` and to enter its symbol into the owning scope.

Second, the assertions that could be tripped in `addDerivedTrees`
and in `ImplicitClassWrapper#derivedSym` have been converted to
positioned errors.

The first change is sufficient to fix this bug, but the second
is also enough to make the enclosed test pass, and has been retained
as an extra layer of defence.
SI-8941 Deterministic tests for pres. compiler idempotency

A retrospective test case which covers typechecking idempotency which
was introduced in 0b78a0196 / 148736c3df. It also tests the
implicit class handling, which was fixed in the previous commit.

It is difficult to test this using existing presentation compiler
testing infrastructure, as one can't control at which point during
the first typechecking the subesquent work item will be noticed.

Instead, I've created a test with a custom subclass of
`interactive.Global` that allows precise, deterministic control
of when this happens. It overrides `signalDone`, which is called
after each tree is typechecked, and watches for a defintion with
a well known name. At that point, it triggers a targetted typecheck
of the tree marked with a special comment.

It is likely that this approach can be generalized to a reusable
base class down the track. In particular, I expect that some of
the nasty interactive ScalaDoc bugs could use this single-threaded
approach to testing the presentation compiler.
SI-8943 Handle non-public case fields in pres. compiler

When a case class is type checked, synthetic methods are added,
such as the `hashCode`/`equals`, implementations of the `Product`
interface. At the same time, a case accessor method is added for
each non-public constructor parameter. This the accessor for a
parameter named `x` is named `x$n`, where `n` is a fresh suffix.

This is all done to retain universal pattern-matchability of
case classes, irrespective of access. What is the point of allowing
non-public parameters if pattern matching can subvert access? I
believe it is to enables private setters:

```
case class C(private var x: String)

scala> val x = new C("")
x: C = C()

scala> val c = new C("")
c: C = C()

scala> val C(x) = c
x: String = ""

scala> c.x
<console>:11: error: variable x in class C cannot be accessed in C
              c.x
                ^

scala> c.x = ""
<console>:13: error: variable x in class C cannot be accessed in C
val $ires2 = c.x
               ^
<console>:10: error: variable x in class C cannot be accessed in C
       c.x = ""
         ^
```

Perhaps I'm missing additional motivations.

If you think scheme sounds like a binary compatiblity nightmare,
you're right: https://issues.scala-lang.org/browse/SI-8944

`caseFieldAccessors` uses the naming convention to find the right
accessor; this in turn is used in pattern match translation.

The accessors are also needed in the synthetic `unapply` method
in the companion object. Here, we must tread lightly to avoid
triggering a typechecking cycles before; the synthesis of that method
is not allowed to force the info of the case class.

Instead, it uses a back channel, `renamedCaseAccessors` to see
which parameters have corresonding accessors.

This is pretty flaky: if the companion object is typechecked
before the case class, it uses the private param accessor directly,
which it happends to have access to, and which duly gets an
expanded name to allow JVM level access. If the companion
appears afterwards, it uses the case accessor method.

In the presentation compiler, it is possible to typecheck a source
file more than once, in which case we can redefine a case class. This
uses the same `Symbol` with a new type completer. Synthetics must
be re-added to its type.

The reported bug occurs when, during the second typecheck, an entry
in `renamedCaseAccessors` directs the unapply method to use `x$1`
before it has been added to the type of the case class symbol.

This commit clears corresponding entries from that map when we
detect that we are redefining a class symbol.

Case accessors are in need of a larger scale refactoring. But I'm
leaving that for SI-8944.