Add option -port to fsc

Option "port" limits compile server lookup and start to given port.
Normally fsc will start a compile server in a random port if no server
is yet running. This can be problematic with firewalls and/or remote
compile servers. Option "port" should not be confused with option
"server" which looks for a compile server in given host and port and
fails if such server is not found.

Automatic tests for command line user interface do not exist at all.
Thus, adding a test for one new option would require designing a whole
new testing method.
And, Or take sets of Props
Remove redundant UniqueSym class.
Debug printing for Any, not AnyRef, to include primitives

Signed-off-by: Gerard Basler <gerard.basler@gmail.com>
Avoid the `CNF budget exceeded` exception via smarter translation into CNF.

The exhaustivity checks in the pattern matcher build a propositional
formula that must be converted into conjunctive normal form (CNF) in
order to be amenable to the following DPLL decision procedure.
However, the simple conversion into CNF via negation normal form and
Shannon expansion that was used has exponential worst-case complexity
and thus even simple problems could become untractable.

A better approach is to use a transformation into an _equisatisfiable_
CNF-formula (by generating auxiliary variables) that runs with linear
complexity. The commonly known Tseitin transformation uses bi-
implication. I have choosen for an enhancement: the Plaisted
transformation which uses implication only, thus the resulting CNF
formula has (on average) only half of the clauses of a Tseitin
transformation.

The Plaisted transformation uses the polarities of sub-expressions to
figure out which part of the bi-implication can be omitted. However,
if all sub-expressions have positive polarity (e.g., after
transformation into negation normal form) then the conversion is
rather simple and the pseudo-normalization via NNF increases chances
only one side of the bi-implication is needed.

I implemented only optimizations that had a substantial
effect on formula size:
- formula simplification, extraction of multi argument operands
- if a formula is already in CNF then the Tseitin/Plaisted
  transformation is omitted
- Plaisted via NNF
- omitted: (sharing of sub-formulas is also not implemented)
- omitted: (clause subsumption)
SI-7596 Curtail overloaded symbols during unpickling

In code like:

    object O { val x = A; def x(a: Any) = ... }
    object P extends O.x.A

The unpickler was using an overloaded symbol for `x` in the
parent type of `P`. This led to compilation failures under
separate compilation.

The code that leads to this is in `Unpicklers`:

    def fromName(name: Name) = name.toTermName match {
      case nme.ROOT     => loadingMirror.RootClass
      case nme.ROOTPKG  => loadingMirror.RootPackage
      case _            => adjust(owner.info.decl(name))
    }

This commit filters the overloaded symbol based its stability
unpickling a singleton type. That seemed a slightly safer place
than in `fromName`.
Correct collections variable definitions to avoid many scaladoc warnings.
SI-8597 Improved pattern unchecked warnings

The spec says that `case _: List[Int]` should be always issue
an unchecked warning:

> Types which are not of one of the forms described above are
> also accepted as type patterns. However, such type patterns
> will be translated to their erasure (§3.7). The Scala compiler
> will issue an “unchecked” warning for these patterns to flag
> the possible loss of type-safety.

But the implementation goes a little further to omit warnings
based on the static type of the scrutinee. As a trivial example:

   def foo(s: Seq[Int]) = s match { case _: List[Int] => }

need not issue this warning.

These discriminating unchecked warnings are domain of
`CheckabilityChecker`.

Let's deconstruct the reported bug:

  def nowarn[T] = (null: Any) match { case _: Some[T] => }

We used to determine that if the first case matched, the scrutinee
type would be `Some[Any]` (`Some` is covariant). If this statically
matches `Some[T]` in a pattern context, we don't need to issue an
unchecked warning. But, our blanket use of `existentialAbstraction`
in `matchesPattern` loosened the pattern type to `Some[Any]`, and
the scrutinee type was deemed compatible.

I've added a new method, `scrutConformsToPatternType` which replaces
pattern type variables by wildcards, but leaves other abstract
types intact in the pattern type. We have to use this inside
`CheckabilityChecker` only. If we were to make `matchesPattern`
stricter in the same way, tests like `pos/t2486.scala` would fail.

I have introduced a new symbol test to (try to) identify pattern
type variables introduced by `typedBind`. Its not pretty, and it
might be cleaner to reserve a new flag for these.

I've also included a test variation exercising with nested matches.
The pattern type of the inner case can't, syntactically, refer to the
pattern type variable of the enclosing case. If it could, we would
have to be more selective in our wildcarding in `ptMatchesPatternType`
by restricting ourselves to type variables associated with the closest
enclosing `CaseDef`.

As some further validation of the correctness of this patch,
four stray warnings have been teased out of
neg/unchecked-abstract.scala

I also had to changes `typeArgsInTopLevelType` to extract the type
arguments of `Array[T]` if `T` is an abstract type. This avoids the
"Checkability checker says 'Uncheckable', but uncheckable type
cannot be found" warning and consequent overly lenient analysis.
Without this change, the warning was suppressed for:

    def warnArray[T] = (null: Any) match { case _: Array[T] => }
SI-5639 Fix spurious discarding of implicit import

In Scala fa0cdc7b (just before 2.9.0), a regression in implicit
search, SI-2866, was discovered by Lift and fixed. The nature of
the regression was that an in-scope, non-implicit symbol failed to
shadow an eponymous implicit import.

The fix for this introduced `isQualifyingImplicit` which discards
in-scope implicits when the current `Context`'s scope contains
a name-clashing entry.

Incidentally, this proved to be a shallow solution, and we later
improved shadowing detection in SI-4270 / 9129cfe9. That picked
up cases where a locally defined symbol in an intervening scope
shadowed an implicit.

This commit includes the test case from the comments of SI-2866.
Part of it is tested as a neg test (to test reporting of ambiguities),
and the rest is tested in a run test (to test which implicits are
picked.)

However, in the test case of SI-5639, we see that the scope lookup
performend by `isQualifyingImplicit` is fooled by a "ghost" module
symbol. The apparition I'm referring to is entered when
`initializeFromClassPath` / `enterClassAndModule` encounters
a class file named 'Baz.class', and speculatively enters _both_ a
class and module symbol. AFAIK, this is done to defer parsing the
class file to determine what inside. If it happens to be a Java
compiled class, the module symbol is needed to house the static
members.

This commit adds a condition that `Symbol#exists` which shines a torch
(forces the info) in the direction of the ghost module symbol. In our
test, this causes it to vanish, as we only need a class symbol for
the Scala defined `class Baz`.

The existing `pos` test for this actually did not exercise the bug,
separate compilation is required. It was originally checked in to
`pending` with this error, and then later moved to `pos` when someone
noticed it was not failing.
SI-5938 Test for a FSC bug with mixin, duplicate static forwarders

Under resident compilation, we were getting multiple copies of static
forwarders created for mixed in methods. It seems like the bug was
fixed as a by-product of #4040.

This commit adds a test to show this. I've confirmed that the test
fails appropriately with 2.11.4.

For future reference, before I figured out how to write the test
for this one (test/resident doesn't seem to let you run the code
after compiling it), I was using bash to test as follows:

    (export V=2.11.x; (scalac-hash $V sandbox/t5938_1.scala; (for i in 1 2; do echo sandbox/t5938.scala; done; printf '\n') | scalac-hash $V  -Xresident); stty echo; scala-hash $V X ; echo ':javap -public X' | scala-hash $V);
SI-8253 Fix incorrect parsing of <elem xmlns={f("a")}/>

The spliced application was placed in the `attrMap` in
`SymbolicXMLBuilder` and later incorrectly matched by a pattern
intended only to match:

    xml.Text(s)

That attribute value is generated by parsing:

   <elem xmlns='a'/>

So the net effect was that the two fragments of XML were identical!

This commit sharpens up the match to really look for a syntactic
`_root_.scala.xml.Text("...")`.

The test just prints the parse trees of a variety of cases, as we
we should not test the modularized XML library in scala/scala.
Let users specify a different location for build repos than user home

This change is helpful e.g. when setting up CI for Scala and it's important which directories are used by a build.
By default it uses .m2, .pax and .sbt/cache from user home (in general $HOME). Sometimes it's not possible to use
this location and also changing a value of $HOME is not an option.

The required location should be specified both for ant's build.xml and used scripts.
In the first case specifying -Duser.home is all, what we need. But we can't just set _JAVA_OPTIONS
as then partest tests fail due to the unexpected output (an additional 'Picked up java options (...)' messages).
We can set ANT_OPTS instead of this. The only problem was that OSGi JUnit tests (only they) were using $HOME anyway.
I forced them to use -Duser.home by propagating this option in build.xml.

binary-repo-lib.sh is changed to use a special env variable or $HOME, when this variable is not set.

Then we can do:

export SCALA_BUILD_REPOS_HOME=<some_dir>
export ANT_OPTS="$ANT_OPTS -Duser.home=$SCALA_BUILD_REPOS_HOME"
ant dist

and it will create all directories .m2, .pax and .sbt/cache in a specified $SCALA_BUILD_REPOS_HOME directory.

Note: maven's settings.xml should be located in this used $SCALA_BUILD_REPOS_HOME/.m2 and point to the
repository like <some_dir>/.m2/repository
SI-8981 Tweak REPL help

Tweak colon command processing.

Fixes an unhelpful message about the ambiguity of colon.
SI-7444 docs: null Executor allowed in ExecutionContext factories

Update the ScalaDoc for the factory methods for `ExecutionContext`
which allow a `null` `Executor`/`ExecutorService`.
SI-7459 Handle pattern binders used as prefixes in TypeTrees.

Match translation was incorrect for:

    case t => new t.C
    case D(t) => new d.C

We would end up with Types in TypeTrees referring to the wrong
symbols, e.g:

    // t7459a.scala
    ((x0$1: this.LM) => {
      case <synthetic> val x1: this.LM = x0$1;
      case4(){
       matchEnd3(new tttt.Node[Any]())
      };
      matchEnd3(x: Any){
        x
    }

Or:
    // t7459b.scala
     ((x0$1: CC) => {
       case <synthetic> val x1: CC = x0$1;
       case4(){
         if (x1.ne(null))
           matchEnd3(new tttt.Node[Any]())
         else
           case5()
       };

This commit:

  - Changes `bindSubPats` to traverse types, as well as terms,
    in search of references to bound symbols
  - Changes `Substitution` to reuse `Tree#substituteSymbols` rather
    than the home-brew substitution from `Tree`s to `Tree`s, if the
    `to` trees are all `Ident`s
  - extends `substIdentsForTrees` to substitute selections like
    `x1.caseField` into types.

I had to dance around the awkward handling of "swatches" (exception
handlers that can be implemented with JVM native type switches) by
duplicating trees to avoid seeing the results of `substituteSymbols`
in `caseDefs` after we abandon that approach if we detect the
patterns are too complex late in the game.

I also had to add an escape hatch for the "type selection from
volatile type" check in the type checker. Without this, the
translation of `pos/t7459c.scala`:

    case <synthetic> val x1: _$1 = (null: Test.Mirror[_]).universe;
    case5(){
      if (x1.isInstanceOf[Test.JavaUniverse])
        {
          <synthetic> val x2: _$1 with Test.JavaUniverse = (x1.asInstanceOf[_$1 with Test.JavaUniverse]: _$1 with Test.JavaUniverse);
          matchEnd4({
            val ju1: Test.JavaUniverse = x2;
            val f: () => x2.Type = (() => (null: x2.TypeTag[Nothing]).tpe);

.. triggers that error at `x2.TypeTag`.
SI-5639 Predicate bug fix on -Xsource:2.12

To be conservative, I've predicated this fix in `-Xsource:2.12`.
This is done in separate commit to show that the previous fix
passes the test suite, rather than just tests with `-Xsource:2.12`.
SI-8597 Expand documentation of CheckabilityChecker

Cherry picking some of the previous commit message.
Merge pull request #4118 from retronym/ticket/5639

SI-5639 Fix spurious discarding of implicit import
Merge pull request #4132 from phaller/ticket/7444

SI-7444 docs: null Executor allowed in ExecutionContext factories
Merge pull request #4123 from retronym/ticket/8253

SI-8253 Fix incorrect parsing of <elem xmlns={f("a")}/>
Fix one typo in the scaladoc of Inliners

The Scaladoc of `Inliners` contained one tiny typo for the word "accessibility".
This PR only fixes this typo.