Merge pull request #3185 from sschaef/update-eclipse-classpath

Update Eclipse classpath files
Test in quick mode for ant build

Add a target `test.suite.quick`.

Let test.quick depend only on init and quick.done,
and load the task using the quick path (with non-core deps).
SI-7872 Plug a variance exploit in refinement types

Refinement types are collapsed to a TypeTree with an original
during type checking; this was enough to evade variance validation
in refchecks.

This commit:

  - validates the original of `TypeTree`s in refchecks
  - changes VarianceValidator to recurse into:
    - the originals of `TypeTree`s
    - `TypTree` (to cover, e.g. `CompoundTypeTree` / `SelectFromTypeTree`)

It also finds an unreported variance violation in an existing
test case, variances.scala. This looks to be legitimate.
Symbol substutition must consider ClassInfoType#parents

An upcoming change to uncurry, in which I plan to make substitution of
`lambda params -> apply method params` requires that I first to fix a
problem in symbol substition.

This situation can arise when the body of this definition:

    def owner1(a: A) = {
        class C extends M[a.B]
    }

is transplanted into a new owner that has a different symbol for `a`.

I speculated that value classes might also be prone to the
fact that symbol substitution neglected `ClassInfoType#parents`.

We can test change with Value Classes:  Partial Functions that are
dependent on value class param type used to fail with a spurious
overriding error, now they work correctly.
Substitute new parameter symbols into lambda body

Previously, new synthetic parameter symbols were created for the
apply method parameters, but only used in its `MethodType`. The
`ValDef` trees of the function, along with their symbols, were
used directly as the parameter trees of the apply method.

    % cat sandbox/test.scala
    object Test {
      (x: Int) => {
        (y: Int) => ???
      }
    }

    % scalac-hash v2.10.3 -Xprint:typer,uncurry -uniqid ../scala2/sandbox/test.scala  | egrep 'syntax|\bx'
    [info] v2.10.3 => /Users/jason/usr/scala-v2.10.3-0-g88b5d19
    [[syntax trees at end of                     typer]] // test.scala
        ((x#12152: Int#351) => x#12152)#12151
    [[syntax trees at end of                   uncurry]] // test.scala
            final def apply#15952(x#12152: Int#351): Int#351 = x#12152

This approach dates back a long way: c64152bc3. @odersky tells me it
was most likely due to insufficent substitution/cloning machinery
at the time.

    % qbin/scalac -Xprint:typer,uncurry -uniqid ../scala2/sandbox/test.scala  | egrep 'syntax|\bx'
    [[syntax trees at end of                     typer]] // test.scala
        ((x#13685: Int#1760) => x#13685)#13671
    [[syntax trees at end of                   uncurry]] // test.scala
            final def apply#13959(x#13960: Int#1760): Int#1760 = x#13960

To make this work, I had to fix a problem in symbol substition; this
was commited in the previous commit. In the enclosed test, at Uncurry,
the symbol of the nested class `N` had a `ClassInfoType`, which listed
as a parent `M[a.C]`. When we substituted the new method parameter
symbol `a` for the eponymous function parameter symbol, this was not
touched.
Refactor away duplication between -Ydelambdafy:{inline,method}
Special treatment for local symbols in TypeTreeMemberType

Avoids calling `thisType` on the owner if it is a term symbol,
which doesn't make much sense.

This method is used internally in tree factory methods that
create, e.g, a `DefDef` based on the info of a `Symbol`.
SI-8001 spurious "pure expression does nothing" warning

`isPureExprForWarningPurposes` doesn’t warn on `()`, but `(): Unit`
leaves it confused. This patch fixes the problem.

The fix is important in the context of the recent split between blackbox
and whitebox macros. Macro engines wrap expansions of blackbox macros
in type ascriptions, so a macro that expands into `()` would actually
produce `(): Unit`, which would trigger a spurious warning. Thanks
@milessabin for spotting this problem!
SI-8002 private access for local companions

We go through similar gymnastics to make companion implicits
work for local class/object pairings, so we ought to be consistent
when it comes to access
Deprecates Par*View and Gen*View

In 2.12, this gives us the option to move the code from
Gen*View down into *View. If we don't do something more
drastic with views, which inertia and history suggests
is a real possibility, we can at least shed a little of
the implementation.

These abstractions are *only* used to share implementation;
there is no `view` method available on, for instance, `GenSeq`
that lets one abstract over parallel/sequential collections
while spawning views.

  scala> (List(1): collection.GenSeq[Int]).view
  <console>:8: error: value view is not a member of scala.collection.GenSeq[Int]
                (List(1): collection.GenSeq[Int]).view
                                                  ^
Let's keep it that way.

I suspect that views over parallel collections exist not because
they were the most sought after feature, but rather because the
initial incarnatin of parallel collections used to live undernead
TraversableOnce, and hence were obligated to implement `def view`.

This change will give us deprecation warnings in the non deprecated
places that extend `Gen*View` (three, by my count) in the interim.
There are ways to avoid this, but they aren't particularly appealing.
Merge pull request #3187 from som-snytt/issue/test-suite-quick

Test in quick mode for ant build
Merge pull request #3165 from retronym/ticket/uncurry-tidy-2

Unifying -Ydelambdafy:{inline, method}
Merge pull request #3130 from retronym/ticket/7967-2

SI-7967 Account for type aliases in self-type checks
Merge pull request #3183 from xeno-by/topic/pure-expression-does-nothing

SI-8001 spurious "pure expression does nothing" warning
Merge pull request #3178 from retronym/ticket/7872

SI-7872 Plug a variance exploit in refinement types
Merge pull request #3147 from som-snytt/issue/repl-columns

SI-7969 REPL -C columnar output
Move all macros in build.xml to build-support.xml.

No functional changes -- in an effort to separate state from behavior.
No longer support unreleased STARR.

The STARR ("stable reference") compiler is used to bootstrap the compiler.
It is now always resolved from maven, based on the `starr.version`
property (stored in `versions.properties`).

Before, we used the `.desired.sha1` mechanism to pull a set of jars
that define the compiler used to build locker ("local reference"),
which then builds quick.

From now on, we only support officially released versions of STARR.
Milestones are allowed of course, which means that, instead of
breaking change, STARR evolution must support old and new behavior
for at least one milestone cycle.

For local development, use the `replacestarr` target as before.
It builds quick (core only) and publishes it to your local maven repo
with a generated version number, which is saved as `starr.version`
in `build.properties` for convenience (overriding `versions.properties`),
so that your next build will use this version of the compiler for STARR.

You may now think of STARR as STAble Reference Release -- if you will.
SI-4332 Plugs the gaps in views

These currently result in runtime errors:

    scala> List(1).view.distinct.force
    java.lang.UnsupportedOperationException: SeqView(...).newBuilder

    scala> List(1).view.inits.toList
    java.lang.UnsupportedOperationException: SeqView(...).newBuilder

Two tests are enclosed:

  1. reflect on the views to make any method that returns
     `Repr` is overriden in `*ViewLike`. This guards against
     new additions to the collections API.
  2. exercise the newly added overrides

Some care is needed with `tail`, we must re-override it
in `mutable.IndexedSeqView` to be explicit about the
end point of the slice, because the `IndexedSeqView#Sliced`
defines length in terms of that. (Higher up the chain, it
is just `iterator.size`, that's why `SeqView#tail` just sets
up a slice from `1 to Int.MaxValue`.)

Parallel collections views are not touched, as these are likely
to be deprecated or removed shortly.

Before this change, the test reported the following.
Not all of these methods were buggy. For instance, `sortBy`,
`sortWith` are implemented in terms of `sorted` which
was implemented in `SeqViewLike`. Even in those cases, I have
opted to override the methods in the `ViewLike` to guard
against changes in the base class implementation and to
simplify the rules in the test.

    ======================================================================
    Checking scala.collection.TraversableView
    ======================================================================

    trait TraversableLike
    ----------------------------------------------------------------------
    def filterNot(p: A => Boolean): Repr
    def inits: Iterator[Repr]
    def tails: Iterator[Repr]
    override def tail: Repr

    ======================================================================
    Checking scala.collection.IterableView
    ======================================================================

    trait IterableLike
    ----------------------------------------------------------------------
    def dropRight(n: Int): Repr
    def sliding(size: Int): Iterator[Repr]
    def takeRight(n: Int): Repr

    trait TraversableLike
    ----------------------------------------------------------------------
    def filterNot(p: A => Boolean): Repr
    def inits: Iterator[Repr]
    def tails: Iterator[Repr]
    override def tail: Repr

    ======================================================================
    Checking scala.collection.SeqView
    ======================================================================

    trait IterableLike
    ----------------------------------------------------------------------
    def dropRight(n: Int): Repr
    def sliding(size: Int): Iterator[Repr]
    def takeRight(n: Int): Repr

    trait SeqLike
    ----------------------------------------------------------------------
    def combinations(n: Int): Iterator[Repr]
    def distinct: Repr
    def permutations: Iterator[Repr]
    def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr
    def sortWith(lt: (A, A) => Boolean): Repr

    trait TraversableLike
    ----------------------------------------------------------------------
    def filterNot(p: A => Boolean): Repr
    def inits: Iterator[Repr]
    def tails: Iterator[Repr]
    override def tail: Repr

    ======================================================================
    Checking scala.collection.mutable.IndexedSeqView
    ======================================================================

    trait IndexedSeqOptimized
    ----------------------------------------------------------------------
    override def dropRight(n: Int): Repr
    override def tail: Repr
    override def takeRight(n: Int): Repr

    trait IterableLike
    ----------------------------------------------------------------------
    def sliding(size: Int): Iterator[Repr]

    trait SeqLike
    ----------------------------------------------------------------------
    def combinations(n: Int): Iterator[Repr]
    def distinct: Repr
    def permutations: Iterator[Repr]
    def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr
    def sortWith(lt: (A, A) => Boolean): Repr

    trait TraversableLike
    ----------------------------------------------------------------------
    def filterNot(p: A => Boolean): Repr
    def inits: Iterator[Repr]
    def tails: Iterator[Repr]

    ======================================================================
    Checking scala.collection.immutable.StreamView
    ======================================================================

    trait IterableLike
    ----------------------------------------------------------------------
    def dropRight(n: Int): Repr
    def sliding(size: Int): Iterator[Repr]
    def takeRight(n: Int): Repr

    trait SeqLike
    ----------------------------------------------------------------------
    def combinations(n: Int): Iterator[Repr]
    def distinct: Repr
    def permutations: Iterator[Repr]
    def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr
    def sortWith(lt: (A, A) => Boolean): Repr

    trait TraversableLike
    ----------------------------------------------------------------------
    def filterNot(p: A => Boolean): Repr
    def inits: Iterator[Repr]
    def tails: Iterator[Repr]
    override def tail: Repr
SI-8011 Test case for recently fixed value class bug

The improvements to symbol substitution in cb37548ef made this
one work.