SI-5652 Mangle names of potentially public lambda lifted methods.

This can happen if they are accessed from an inner class. If a
subclass is happens to lift a public method to the same name,
a VerifyError ensues.

The enclosed tests:
 - demonstrate the absense of the VerifyError
 - show the names generated for the lifted methods (which are
   unchanged if not called from an inner class, or if lifted
   into a trait implementation class.)
 - ensure that the callers are rewritten to call the correct
   method when multiple with the same name are lifted.

It's not ideal that this phase needs a priori knowledge of the
later phases to perform this mangling. A better fix would defer
this until the point when the methods are publicised, and leave
the unmangled private method in place and install an public,
mangled forwarder.
Help our new exhaustiveness checker.

...be a little less chatty.
Orphan checkfile remover.

Are these -msil checkfiles used in some secret fashion? The level of
activity suggest otherwise.  Since scala-nightly-msil has been disabled
for over a year, it's an easy rm unless someone speaks up.

  % tools/rm-orphan-checkfiles
  Scanning for orphan check files...
  rm 'test/disabled/run/code.check'
  rm 'test/files/jvm/t1652.check'
  rm 'test/files/neg/macro-argtype-mismatch.check'
  rm 'test/files/neg/macro-noncompilertree.check'
  rm 'test/files/neg/macro-nontree.check'
  rm 'test/files/run/Course-2002-01-msil.check'
  rm 'test/files/run/Course-2002-02-msil.check'
  rm 'test/files/run/Course-2002-03-msil.check'
  rm 'test/files/run/Course-2002-04-msil.check'
  rm 'test/files/run/Course-2002-08-msil.check'
  rm 'test/files/run/Course-2002-09-msil.check'
  rm 'test/files/run/Course-2002-10-msil.check'
  rm 'test/files/run/absoverride-msil.check'
  rm 'test/files/run/bitsets-msil.check'
  rm 'test/files/run/boolord-msil.check'
  rm 'test/files/run/bugs-msil.check'
  rm 'test/files/run/impconvtimes-msil.check'
  rm 'test/files/run/infix-msil.check'
  rm 'test/files/run/iq-msil.check'
  rm 'test/files/run/macro-invalidret-doesnt-conform-to-impl-rettype.check'
  rm 'test/files/run/macro-rettype-mismatch.check'
  rm 'test/files/run/misc-msil.check'
  rm 'test/files/run/promotion-msil.check'
  rm 'test/files/run/richs-msil.check'
  rm 'test/files/run/runtime-msil.check'
  rm 'test/files/run/tuples-msil.check'
  rm 'test/pending/jvm/t1464.check'
  rm 'test/pending/run/subarray.check'
  rm 'test/pending/run/t0446.check'
  rm 'test/pending/run/t5629.check'
  Scanning for orphan flags files...
  rm 'test/files/neg/macro-argtype-mismatch.flags'
  rm 'test/files/neg/macro-noncompilertree.flags'
  rm 'test/files/neg/macro-nontree.flags'
  rm 'test/files/pos/anyval-children.flags'
  rm 'test/files/pos/t3097.flags'
  rm 'test/files/run/macro-invalidret-doesnt-conform-to-impl-rettype.flags'
  rm 'test/files/run/macro-rettype-mismatch.flags'
Handled some of our new exhaustiveness warnings.

Who could have suspected it would actually be right most of the time?
Fix a NSDNHAO in extension methods.

A bridge method, created when we override a method from
a superclass and refine the return type, was appearing
as an overloaded alternative. (`erasure` doesn't create
new scopes, so the bridges it builds are visible at
earlier phases.)

The problem was masked when compiling with specialization,
which *does* create a new scope, shielding the code in
question from the artefacts of erasure.

To fix the problem, we filter out bridge methods from
the overloaded alternatives returned by `.decl`, as would
happen internally in `.member`.
SI-4579 Yoke the power of lisp.scala as a stress for the optimizer.

The reported bug was fixed between 2.10.0-M1 and 2.10.0-M2.
Merge pull request #633 from retronym/topic/value-class-bridge

Fix a NSDNHAO in extension methods.
SI-5845 Advances the example from a crasher to an inference failure.

The inference failure itself seems like an instance of of SI-3346.

But dependent method types (which triggered the crash), can be employed
to avoid inferring the type constructor CC.

class Num[T] {
  def mkOps = new Ops
  class Ops { def +++(rhs: T) = () }
}

class A {
  implicit def infixOps[T](lhs: T)(implicit num: Num[T]): num.Ops = num.mkOps
  implicit val n1: Num[Int] = new Num[Int] { }
  5 +++ 5
}
don't check exhaustivity involving user-defined unapplySeq
handle approximating alternative of empty pattern
Merge pull request #635 from adriaanm/topic/virtpatmat

fixes for exhaustivity
Merge pull request #636 from retronym/ticket/5845

SI-5845 Advances the example from a crasher to an inference failure.
fix t5843
Implemented functionality to invalidate classpath entries, to enable incremental compiles.
Merge pull request #640 from odersky/topic/inkling

Implemented functionality to invalidate classpath entries
Merge pull request #634 from retronym/ticket/4579

SI-4579 Yoke the power of lisp.scala as a stress for the optimizer.
Merge pull request #638 from lrytz/wip/t5843

fix t5843
Partial redesign of incremental compiler invalidation.

We now do the right thing when packages are either newly created or deleted. Previously there was a problem when a new package was created inside a system package (and, unofrtunately, root is a system package). That's fixed now. We also approximate more tightly now when packages are newly created (iei the newly created symbol gets rescanned, instead of its owner).

Incremental class invalidation: dealing with empty package.

The compiler can now also invalidate the empty package. Previously, no invalidation was done because empty was identified with root, which is considered a system package.

(1) Fixed NPE when creating a new toplevel package in invalidation. (2) generalized interface to deal with multiple entries at a time.
Merge pull request #645 from odersky/topic/inkling-consolidated

Partial redesign of incremental compiler invalidation.
skipping unnecessary work in GenASM when emitting 1.5 classfiles