Fix dependant => dependent
SI-6803: do not use java.net.URI, even more so incorrectly.
SI-6923 Context now buffers warnings as well as errors

Code that was silently typed would not report warnings, even if it
returned a successful result.

This appeared in the following code which didn't show warnings even
with -Ywarn-adapted-args:

    def foo(a: Any) = a; foo(1, 2)

While the following would show the expected warning:

    def foo[A](a: Any) = a; foo(1, 2)
SI-6928, VerifyError with self reference to super.

A bug in typers mishandled varargs. We should get more
aggressive about eliminating all the ad hoc parameter/argument
handling code spread everywhere. For varargs especially:
any code which tries to make an adjustment based on a
repeated parameter is more likely to be wrong than right.
In aggregate these reinventions are a huge source of bugs.
sbt-git-plugin has moved.

We need to eliminate these sort of shifting sands to make
the SBT build a viable option.
SI-6912 Avoid a typer cycle in overload resolution.

c800d1fe, and followup commits 1ddc9358 and b10b5821
modified error handling in `Infer#inferExprAlternative`.
After these changes, this method could fail to resolve
the overloaded alternative if:

     best != NoSymbol
  && !competing.isEmpty
  && !noAlternatives
  && pt.isErroneous

This commit calls `setError` in that case, which
prevents the cycle in `adapt`.

While I didn't extract a reproduction from the
original code base, I've included a test case that
exhibits the same symptom.

It was actually pretty tough to find an program that
got close to this code path, but luckilly we've been
pretty close to this bug in SI-5553 / 4f99c2e5, and those
test cases formed the basis for this one.
SI-6930 adds documentation to reduceLeft in TraversableOnce
SI-6641 Cull scala.swing.SwingWorker

It appears to do nothing much at all, refers to the now-deprecated
scala.actor package, and has a name clash with an important class
from java.swing.

Note that the POM for scala-swing does not declare the dependency.

The final nail in the coffin is it aides and abets the crash in
the crash in SI-6440.

Attempts to remove or even deprecate this in 2.10.0 were
missed the boat.

This commit removes them for 2.11.0, in contravention of
the deprecation policy. Given that they rely on the
scala-actors module which _is_ deprecated in 2.10.0,
and will likely be removed in 2.11.0, I contend that
this is a reasonable exception.
Actor.scala
SI-6641 Deprecate SwingWorker

See discussion: https://github.com/scala/scala/pull/1862
Fixes SI-6521, overrides Range#head to be faster

Backport of 63ba3d64a7002ef67f7f13083a18fe1042a3adba
Backport of SI-6846.

Squashed commit of the following:

commit 55806cc0e6177820c12a35a18b4f2a12dc07bb39
Author: Paul Phillips <paulp@improving.org>
Date:   Wed Dec 19 07:32:19 2012 -0800

    SI-6846, regression in type constructor inference.

    In 658ba1b4e6 some inference was gained and some was lost.
    In this commit we regain what was lost and gain even more.
    Dealiasing and widening should be fully handled now, as
    illustrated by the test case.
    (cherry picked from commit dbebcd509e4013ce02655a2687b27d0967b3650e)

commit e6ef58447d0f4ef6de956fcc03ee283bb9028c02
Author: Paul Phillips <paulp@improving.org>
Date:   Fri Dec 21 15:11:29 2012 -0800

    Cleaning up type alias usage.

    I determined that many if not most of the calls to .normalize
    have no intent beyond dealiasing the type. In light of this I
    went call site to call site knocking on doors and asking why
    exactly they were calling any of

      .normalize
      .widen.normalize
      .normalize.widen

    and if I didn't like their answers they found themselves
    introduced to 'dropAliasesAndSingleTypes', the recursive widener
    and dealiaser which I concluded is necessary after all.

    Discovered that the object called 'deAlias' actually depends
    upon calling 'normalize', not 'dealias'. Decided this was
    sufficient cause to rename it to 'normalizeAliases'.

    Created dealiasWiden and dealiasWidenChain.

    Dropped dropAliasesAndSingleTypes in favor of methods
    on Type alongside dealias and widen (Type#dealiasWiden).
    These should reduce the number of "hey, the type alias doesn't work" bugs.

    (cherry picked from commit 3bf51189f979eb0dd41744ca844fd12dfdaa0dee)

    Conflicts:
    	src/compiler/scala/tools/nsc/interpreter/CompletionOutput.scala

commit c1d8803cea1523f458730103386d8e14324a9446
Author: Paul Phillips <paulp@improving.org>
Date:   Sat Dec 22 08:13:48 2012 -0800

    Shored up a hidden dealiasing dependency.

    Like the comment says:

    // This way typedNew always returns a dealiased type. This
    // used to happen by accident for instantiations without type
    // arguments due to ad hoc code in typedTypeConstructor, and
    // annotations depended on it (to the extent that they worked,
    // which they did not when given a parameterized type alias
    // which dealiased to an annotation.) typedTypeConstructor
    // dealiases nothing now, but it makes sense for a "new" to
    // always be given a dealiased type.

    PS:
    Simply running the test suite is becoming more difficult all
    the time. Running "ant test" includes time consuming activities
    of niche interest such as all the osgi tests, but test.suite
    manages to miss the continuations tests.
    (cherry picked from commit 422f461578ae0547181afe6d2c0c52ea1071d37b)

commit da4748502792b260161baa10939554564c488051
Author: Paul Phillips <paulp@improving.org>
Date:   Fri Dec 21 12:39:02 2012 -0800

    Fix and simplify typedTypeConstructor.

    Investigating the useful output of devWarning (-Xdev people,
    it's good for you) led back to this comment:

      "normalize to get rid of type aliases"

    You may know that this is not all the normalizing does.
    Normalizing also turns TypeRefs with unapplied arguments
    (type constructors) into PolyTypes. That means that when
    typedParentType would call typedTypeConstructor it would
    find its parent had morphed into a PolyType. Not that it
    noticed; it would blithely continue and unwittingly discard
    the type arguments by way of appliedType (which smoothly
    logged the incident, thank you appliedType.)

    The simplification of typedTypeConstructor:

    There was a whole complicated special treatment of AnyRef
    here which appears to have become unnecessary. Removed special
    treatment and lit a candle for regularity.

    Updated lots of tests regarding newly not-so-special AnyRef.
    (cherry picked from commit 394cc426c1ff1da53146679b4e2995ece52a133e)

commit 1f3c77bacb2fbb3ba9e4ad0a8a733e0f9263b234
Author: Paul Phillips <paulp@improving.org>
Date:   Fri Dec 21 15:06:10 2012 -0800

    Removed dead implementation.

    Another "attractive nuisance" burning off time until I
    realized it was commented out.
    (cherry picked from commit ed40f5cbdf35d09b02898e9c0950b9bd34c1f858)
Merge pull request #1787 from vigdorchik/si_6803

SI-6803: do not use java.net.URI, even more so incorrectly.
SI-6555 Scaladoc's class filter shouldn't drop the last character

The event handler have to wait "keyup", not "keydown".
adds c.macroRole

Currently there's only one flavor of macros - def macros, and the plan
was to gradually introduce additional flavors, such as type macros and
macro annotations.

However as shown by the experience with type macros, it makes sense
to distinguish subflavors of macros that tell us in which context the
macro gets expanded. For def macros we have the only role - expansion
of an application. But for type macros there are multiple.
SI-5903 extractor macros do work

Apparently it is already possible to use macros to customize pattern
matching as described in the comments to the aforementioned JIRA issue.

What's even better - with the incoming addition of c.introduceTopLevel
it becomes possible to generate arbitrarily complex unappliers, even
with heterogeneous types of arguments varying from expansion to expansion
refactors handling of macros in repl

Macros now have a dedicated member handler, so that the logic of their
processing doesn't get mixed up with vanilla DefHandler.

I've also factored out an abstract MacroHandler to provides a basis
to build the upcoming type macro handler upon.
makes macro override error more consistent
adds Trees.replace(Tree, Tree)

Currently dead code. Has proven to be useful to implement type macros,
therefore I'm moving it to scala.reflect.internal.Trees.
fixes printing of AppliedTypeTree
changes isTermMacro checks to something more universal

Previously I wanted to be as precise as possible, but as the experience
with type macros shows, a lot of isTermMacro checks should also extend
to include type macros.

Therefore I'm changing the checks to isMacro. This doesn't make any
difference for existing code, but will reduce the amount of changes
in the upcoming type macro pull request.