[backport] SI-5378, unsoundness with type bounds in refinements.

As the comment says:

Not enough to look for abstract types; have to recursively check
the bounds of each abstract type for more abstract types. Almost
certainly there are other exploitable type soundness bugs which
can be seen by bounding a type parameter by an abstract type which
itself is bounded by an abstract type.

SPECIAL: BUY ONE UNSOUNDNESS, GET ONE FREE

In refinement types, only the first parameter list of methods
was being analyzed for unsound uses of abstract types. Second
parameter list and beyond had free unsoundness reign. That bug
as well is fixed here.
[backport] SI-6301 / SI-6572 specialization regressions

Squashed commit of the following:

commit a3680be29ccd5314c5d027d473b37940eaecd530
Author: Paul Phillips <paulp@improving.org>
Date:   Fri Aug 31 10:20:16 2012 -0700

    Actual fix for SI-6301, specialized crasher.

    This means the workaround in the previous commit is no
    longer reached, but it should remain where it is as a much
    needed layer of robustness/useful error reporting.

    Conflicts:
    	src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
    	src/compiler/scala/tools/nsc/typechecker/Duplicators.scala

commit f4c45ae204ce3ff3c16b19cab266d0b6515b6e0f
Author: Paul Phillips <paulp@improving.org>
Date:   Fri Aug 31 10:49:24 2012 -0700

    Rewrite of GenICode adapt.

    Started for debuggability, stayed for clarify/performance.

    Conflicts:
    	src/compiler/scala/tools/nsc/backend/icode/GenICode.scala

commit 74842f72a0af485e5def796f777f7003f969d75b
Author: Paul Phillips <paulp@improving.org>
Date:   Fri Aug 31 08:45:34 2012 -0700

    Workaround for SI-6301, @specialize crasher.

    SpecializeTypes is generating symbols with overloaded types
    which then proceed to crash in CleanUp or GenICode.  Until I
    or someone works out why that is, take a look in case the
    overload is easily disambiguated by the argument list arity,
    in which case warn and proceed.
SI-6572 Test case, originally fixed in a3680be.

That fix has now been backported to 2.10.x in the
previous commit. This commit should be be merged
to master.
Test case for SI-7009.

The next commit fixes the problem itself and it's easier to see
in diff what's being fixed exactly.
SI-2418, remove restriction on final vars.

[backport]
The original fix for SI-2418 excluded final vars entirely, but
the problem was not final vars per se, but the emission of ACC_FINAL
in combination with ACC_VOLATILE.  Since vars never get ACC_FINAL
now, this is no longer an issue.
SI-4729, overriding java varargs in scala.

[backport]
This was a bad interaction between anonymous subclasses
and bridge methods.

  new Foo { override def bar = 5 }

Scala figures it can mark "bar" private since hey, what's
the difference.  The problem is that if it was overriding a
java-defined varargs method in scala, the bridge method
logic says "Oh, it's private? Then you don't need a varargs
bridge." Hey scalac, you're the one that made me private!
You made me like this! You!

Conflicts:
	src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
SI-5130, precision disappearing from refinement.

[backport]
Remove some code, win a prize.
SI-5353, imperfect error message.

[backport]
The fix of course is a perfect error message.
SI-5859, inapplicable varargs.

[backport]
And other polishing related to varargs handling.
SI-5604, selections on package objects.

[backport]
mkAttributedSelect, which creates a Select tree based on
a symbol, has been a major source of package object bugs,
because it has not been accurately identifying selections
on package objects.  When selecting foo.bar, if foo turns
out to be a package object, the created Select tree must be

  foo.`package`.bar

However mkAttributedSelect was only examining the owner of
the symbol, which means it would work if the package object
defined bar directly, but not if it inherited it.
SI-6072, crasher with overloaded eq.

[backport]
You don't want to do name-based selections in later phases
if you can help it, because there is nobody left to resolve
your overloads.  If as in this example you're calling a
known method, use the symbol.  Review by @hubertp.
SI-6426, importable _.

[backport]
Prohibit `_` as an identifier, it can only bring badness.
SI-6584, Stream#distinct uses too much memory.

[backport]
Nesting recursive calls in Stream is always a dicey business.
SI-6595, lost modifiers in early defs.

[backport]
Saw this by accident; the trees created for early defs would
wholesale replace the modifiers with PRESUPER rather than
combining them. FINAL was lost that way, as would be any other
modifiers which might be valid there.
SI-7009: `@throws` annotation synthesized incorrectly

The 990b3c7 made `scala.throws` annotation polymorphic but forgot to
adapt compiler code that synthesizes it, e.g. when parsing class files.

The consequence was that we would get non-deterministically either
`scala.throws` or `scala.throws[T]` as a type for synthesized annotation.
The reason is that `Symbol.addAnnotation` would call `tpe` method which
does not initialization of symbol so type parameters list would not be
determined correctly. Only if info of that symbol was forced for other
reason we would get `scala.throws[T]`. That non-deterministic behavior
was observed in sbt's incremental compiler.

Another problem we have is that Scala allows polymorphic exceptions
so in ClassfileParser we could synthesize `@throws` annotation with
wrong (polymorphic) type applied. In such case the best we can do
is to convert such type to monomorphic one by introducing existentials.

Here's list of changes this commit introduces:
  * The `Symbol.addAnnotation` that takes symbol as argument asserts
    that the type represented by that symbol is monomorphic (disabled
    due to cycles; see comments in the code)
  * Introduce `Symbol.addAnnotation` overload that allows us to pass
    an applied type
  * Change all places where polymorphic annotations are synthesized
    to pass an applied type
  * Handle polymorphic exception types in
    `ClassfileParser.parseExceptions`

Fixes SI-7009.
evicts eponymous packages and objects from tests

As I figured out from http://groups.google.com/group/scala-internals/browse_thread/thread/ace970a799dcf7a0,
current behavior with same-named objects silently taking precedence over
same-named packages is a bug and shouldn't be relied upon.
the scanner is now less eager about deprecations

When healing braces it isn't very useful to report deprecation warnings,
especially since this process is just simple context-free skimming, which
can't know about what positions can accept what identifiers.

Backport from https://github.com/scala/scala/pull/1807.
Original commit is https://github.com/scala/scala/commit/e5d34d70499504e085ddf957c1c818ffb63f4e8d.
changes the flags to not depend on partest

Due to some reason, partest always enables -deprecation. Since Paul has
just submitted a pull request, which removes this behavior, I'm updating
the flags to make sure this test works even after Paul's change.

Backport from https://github.com/scala/scala/pull/1807
Original commit is https://github.com/scala/scala/commit/2015ad3ebd833225e93ed19604760a6da2522bb1
[backport] Removed restriction on final vars, SI-2418.

Backport of b79c7600544db9964c228b94a2f70f3ed854f89b

The original fix for SI-2418 excluded final vars entirely, but
the problem was not final vars per se, but the emission of ACC_FINAL
in combination with ACC_VOLATILE.  Since vars never get ACC_FINAL
now, this is no longer an issue.
Merge pull request #2021 from gkossakowski/issue/SI-7009

SI-7009: `@throws` annotation synthesized incorrectly