SI-7200 Test case for fixed type inference error.

Broken in 2.9.2 and 2.10.0, but working in 2.10.1

--- sandbox/2.10.0.log
+++ sandbox/2.10.1.log
       def coflatMap[A >: Nothing <: Any, B >: Nothing <: Any](f: Test.Nel[A] => B): Test.Nel[A] => Test.Nel[B] = ((l: Test.Nel[A]) => Test.this.Nel.apply[B](f.apply(l), l.tail match {
         case immutable.this.Nil => immutable.this.Nil
-        case (hd: A, tl: List[A])scala.collection.immutable.::[A]((h @ _), (t @ _)) => {
-          val r: Test.Nel[Nothing] = NelFoo.this.coflatMap[A, Nothing](f).apply(Test.this.Nel.apply[A](h, t));
+        case (hd: A, tl: List[A])scala.collection.immutable.::[?A1]((h @ _), (t @ _)) => {
+          val r: Test.Nel[B] = NelFoo.this.coflatMap[A, B](f).apply(Test.this.Nel.apply[A](h, t));
           {
-            <synthetic> val x$1: Nothing = r.head;
-            r.tail.::[Nothing](x$1)
+            <synthetic> val x$1: B = r.head;
+            r.tail.::[B](x$1)
           }
         }
       }))

b74c33eb86 represents the exact moment of progression. Comments
in pos/t7200b.scala, a minimal test that demonstrates the problem
without type constructors or code execution, pinpoint the line of
code responsible for the fix.

Incidentally, I'm currently on a train somewhere between Solothurn
and Biel, and am consequently without the power of scala-bisector.
Undeterred, and inspired by a line I saw in Skyfall last night
("sometimes the olds ways are better"), I just pulled off a two-hop
bisection. Take that, O(log N)!

The one remaining worry is the appearance of the type variable
?A1 in the output of -Xprint:typer for run/t7200.scala.
SI-7337 Error out on missing -d directory.

This check was removed without comment in 3a30af154, the addition
of JSR-223 support for the interpreter.

After this commit, I manually tested that JSR-223 support works.

    scala> import javax.script._, collection.JavaConverters._; val manager = new ScriptEngineManager; manager.getEngineByName("scala").eval("List(1)")
    import javax.script._
    import collection.JavaConverters._
    manager: javax.script.ScriptEngineManager = javax.script.ScriptEngineManager@4418f61b
    res1: Object = List(1)

3a30af154 did not include a test case, so I don't know whether I've
broken some other aspect of it. I tried the above as a `run` test,
but hit two problems, one of them seemingly our fault, and the other
a MacOS JDK wrinkle.

  1. scala.reflect.internal.MissingRequirementError: object scala.runtime in compiler mirror not found.
  2. java.lang.UnsatisfiedLinkError: no AppleScriptEngine in java.library.path

I can't find my way to fix these, so JSR-223 remains untested. I don't
think that commit was really up to standard; it could handle additional
review, documentation, and testing. It might even be modularized so as
not to pollute the REPL itself.
SI-7080 improve boundary value checking for BitSet

When BitSet accepts a very large integer such as Int.MaxValue,
integer overflow possibly occurs in the calculation of boundary
value "nwords * WordLength". This faulty boundary condition
causes empty-iterator problem like following:

scala> import collection.mutable.BitSet
import collection.mutable.BitSet

scala> val x = BitSet(Int.MaxValue)
x: scala.collection.mutable.BitSet = BitSet()

scala> x.iterator
res0: Iterator[Int] = empty iterator
SI-7329 duplicate default getters for specialized parameters.

The default getter is generated with @specialized annotation if the
type parameter corresponding to the type of the parameter is
specialized. Consequently specialize pass tries to generate overloads.

Rather than pruning overloads to exclude duplicates, let's notice
that default getter specialization is not needed at all:
  - The dynamic scope of default getter doesn't include specialized
    method or class constructor.
  - generic default getter is called even when calling specialized
    method:
    object V {
      @specialized def foo[@specialized B](b: B = (??? : B)) = {}
      foo[Int]()
    }
    gives:
      invokevirtual Method V$.foo$default$1:()Ljava/lang/Object;
      invokestatic (unboxToInt)
      invokevirtual Method V$.foo$mIc$sp:(I)V
SI-7330 better error when pattern isn't a value

Somehow an applied type managed to sneak past the type checker in pattern mode.
Patterns must be values, though.

`case C[_] =>` was probably meant to be `case _: C[_] =>`
Advice is dispensed accordingly. (Generalizing the existing advice machinery.)
Remove scaladoc deprecated option.

Remove -external-urls that had been previously deprecated in 2.10.
SI-7319 Clear error buffer during Typer reset.

Contexts share error/warning buffers with their
children, and this also applies ot the shared
`startContext`.

That context flushes the buffers in `startContext`
in `resetContexts`.

It also removes `typerReportAnyContextErrors`, which
appears to be an elaborate no-op. It is only ever passed
a context `c` which is a direct child of `this.context`.
So taking a buffered error out of `c` and reissuing it
into `this.context` merely re-inserts into into the same
error buffer. Consrast this with `silent`, which uses
a child context with a fresh error buffer.

SI-7319 Flush error buffer in typerReportAnyContextErrors.

After this change, we no longer rely on the backstop in resetContexts
introduced in the previous commit.
SI-7376 Scaladoc warns when discarding local doc comments with API tags

Double-star doc comments in non-dockable positions at the end of a block
will emit a warning only if API tags like @author are present, or under
-Xlint.

A real comment parser is applied early to probe for tags, to minimize
ad hoc testing or duplication, but warnings are suppressed. Residual
ad hockiness lies in precisely which tags to warn on.  Ad hoc or ad doc.

This fix is a stop gap; a richer solution would also report about other
doc locations that won't be processed.
Change unrecognized scaladoc comments to C-style
SI-7377 Fix retypechecking of patterns on case companion alias

Some ancient code in Typers switches from PATTERNmode to
EXPRmode when encountering `stableF(...)`. It just
typechecks `stableF` and discards the arguments.

To the best of Martin's recollection, this has something
to do with the need to typecheck patterns rather late in
the compiler, after `a.b` had been translated to `a.b()`
in `Uncurry`. I'm not able to motivate this with tests
using `-Xoldpatmat`; was there ever an even older pattern
matcher that ran *after* uncurry?

What changed in 2.10.1 to expose this wrinkle? dfbaaa17
fixed `TypeTree.copyAttrs` to copy the original tree.
During the descent of `ResetAttrs`, sub-trees are duplicated
before begin further transformed. Duplicating the `Match`
in 2.10.0 would forget that the original tree of:

    pat = (a: Int)Foo(_)
          `----------`
               `- TypeTree((a: Int)Foo), with original Select(..., "FooAlias")

The retypechecking would operate on the `MethodType`, rather
than the `Select`, which was not considered a stable
application.

For 2.10.x, I've just tightened up the condition to only
hit this if `args` is empty. I'm almost certain that the code
can be removed altogether, and I'll do that when this is merged
to master.
Interactive scaladoc: mark new typer run when done.

As of now, when backgroundCompile is in the same typer run as
scaladoc-fetching logic, typer is confused with stale symbols.
SI-7376 Unmoored doc has correct position

The unmoored DocComment is created more eagerly so that its position
is correct despite subsequent line comments. (Previously, skipComment
would advance docPos.)

It looks like the error caret is still off by one when a doc comment
shows up in the middle of an operator, and who doesn't scaladoc the
interior of expressions?

Another bug fixed by Paul's refactor is that additional comments
between the doc and the entity no longer breaks the scaladoc.
Test added.
Rewrite TailCalls for performance and immutability.

While logging symbols created after typer, I discovered that
TailCalls was far and away the largest creator. It turns out
this was due to a bug where thousands of labels were eagerly
created during tail call analysis, even if the method weren't
tail recursive and no label would ever be required.

This commit shaves 10% off the total number of method symbol
creations (compiling quick.lib drops from 88K to 80K.)
Absolute path in error message.

As soon as you have a directory called "language" lying around,
you will appreciate why the advice given regarding SIP-18
should be "import scala.language..." not "import language..."
SI-7376 Additional trivial Scaladoc format corrections

Horizontal rule is ---- not ==== (which means header).

Sample dollars must be escaped.
SI-7376 Bad doc variable error is positioned at the variable.

For a bad $variable, the caret is positioned at the variable
in the doc instead of at the symbol being documented.
Quiet down overloaded implicit warning.

Apparently implicit classes product both a method symbol and
a module symbol, both of which are marked implicit, which left
this warning code believing there was an overloaded implicit
method.
SI-7388 Be more robust against cycles in error symbol creation.

`Symbol#toString` was triggering `CyclicReferenceError` (specifically,
`accurateKindString` which calls `owner.primaryConstructor`.)

The `toString` output is used when creating an error symbol to
assign to the tree after an error (in this case, a non-existent
access qualifier.)

This commit catches the error, and falls back to just using the
symbol's name.
SI-7314 Partest locates tools.jar and javac

This commit lets partest locate tools.jar the way REPL does, with
the addition that java.home.parent is also tried.

The partest script will use JAVAC_CMD if set, or else JAVA_HOME, and
will try the sibling of JAVACMD if set (on the theory that if you specify
java, you are avoiding the path lookup and javac may also be in
that special place), or else query the path for javac.

The use cases are: no env vars, look around java.home; JDK or JAVA_HOME is
set; JAVACMD is set; and finally tools.jar can live in jre/lib/ext and
the fallback deep search will find it.

These cases have been tried on cygwin with Java installed under
s"Program${space}Files", which is usually the most brittle environment.
That means tested with bash.

The windows partest.bat has not been upgraded or side-graded.
Merge pull request #2338 from som-snytt/issue/7314-test-tools-jar

SI-7314 Partest locates tools.jar and javac