Don't use runtime reflection from the batch compiler.

Not only does this save a big chunk of time on startup by avoiding
classloading and symbol table population, but it also seems to
improve steady state performance of the compiler.

Theory: JIT can optimize more aggressively without the
SynchronizedXxx decorators and the like being in the classloader.
See "Class Heirarchy Analyis" in [1]

This commit does this by:

  - Avoiding use of FromString in pattern matcher, instead
    using an established mechanism to parse system properties.
  - Changes FromString back to use OptManifest. AFAICT, this
    is now only a dependency of scala.tools.cmd.gen.Codegen,
    so this is just a defensive measure.

The REPL still uses runtime reflection, so will pay a little
performance tax.

Benchmark:

    avg shortest 10 times 744ms  # before
    avg shortest 10 times 675ms  # after

[1] https://wikis.oracle.com/display/HotSpotInternals/PerformanceTechniques
Make future-spec tests not spawn threads in constructors.
The future-spec tests were spawning threads in object constructors which
meant they were on the ragged edge of entering deadlock from the static
initialization lock acquired during the static initialization blocks we
use to construct object reference fields. My work on restructuring
lambdas pushed it over the edge. This commit refactors the tests to use
class constructors rather than object constructors.
Add a skeletal Delambdafy phase.
This commit adds a do-nothing phase called "Delambdafy" that will
eventually be responsible for doing the final translation of lambdas
into classes.
SI-7776 post-erasure signature clashes are now macro-aware

"double definition: macro this and method that have same type after erasure"
This error doesn't make sense when macros are involved, because macros
expand at compile-time, where we're not affected by erasure. Moreover,
macros produce no bytecode, which means that we're safe from VerifyErrors.
SI-7634 resurrect the REPL's :sh command

ProcessResult had a companion object in 2.10 that somehow disappeared in
2.11. It only called "new ProcessResult(...)", so the REPL might just as
well do that.
Adds a setting to delay delambdafication. If set then uncurry lifts
the body of a lambda into a local def. Tests are included to show the
different tree shapes.
Refactor Erasure for delambdafication.
This commit is purely a refactor. It pulls code needed to adapt a tree
of one type into a tree of another type (by casting, boxing, coercing,
etc) out of Erasure and into common locations that will be usable
from the Delambdafy phase.
Flesh out the Delambdafy phase.

This commit puts a real body on the Delambdafy phase.

 From a lambda, Delambdafy will create
 1) a static forwarder at the top level of the class that contained
      the lambda
 2) a new top level class that
      a) has fields and a constructor taking the captured environment
(including possbily the "this" reference)
      b) an apply method that calls the static forwarder
      c) if needed a bridge method for the apply method
 3) an instantiation of the newly created class which replaces the
   lambda

Trees.scala is modified to add two more convenient factories
for templates and classdefs.

A few basic tests are included to verify that it works as expected.
Further commits will have additional tests.
Make GenASM not eliminate loadmodule on static methods.
During development of delayed delambdafy there was a problem where
GenASM would eliminate a loadmodule for all methods defined within that
module even if those methods were static. The result would be broken
byte code that failed verification. This commit fixes that and adds a
test.
Make specialization aware of anonymous functions.
During development of late delmabdafying there was a problem where
specialization would undo some of the work done in uncurry if the body
of the lambda had a constant type. That would result in a compiler crash
as when the delambdafy phase got a tree shape it didn't understand.
This commit has a fix and a test.
Create test variants where delambdafication alters signatures.
This commit includes several tests where there's a variation in
signatures between inline delambdafication and method based
delambdafication.
Force several tests to run using inline delambdafication.
The differences when running with method based delambdafication aren't
important enough yet to create specialized versions that use method
based delambdafication.
Merge pull request #3095 from retronym/topic/opt-no-runtime-reflect

Don't use runtime reflection from the batch compiler.
Updated Eclipse .classpath of partest and scaladoc projects

The version of some of the dependencies used in partest and scaladoc projects
did not match the version defined in `version.properties`. This prevented the
above projects from compiling correctly because the old dependencies were not
available in the local maven repository.
Removed Eclipse .project and .classpath for `plugintemplate` project

According to @gkossakowski this project doesn't need to be imported (and,
furtheremore, importing it in the current form results in errors in Eclipse),
hence I'm removing it.
Updated instructions for setting up Eclipse for Scala development
Merge pull request #3104 from dotta/update-eclipse-setup-instructions

Update eclipse setup instructions
Merge pull request #3081 from JamesIry/wip_delayed_delambdafy_cleanup

Delay delambdafication and put the lambda's body into the containing class
Merge pull request #3042 from gourlaysama/t7634-repl-sh-is-broken

SI-7634 resurrect the REPL's :sh command
Collections library tidying and deprecation.  Separate parts are listed below.

Collections library tidying, part one: scripting.

Everything in scala.collection.scripting is deprecated now, along with the
<< method that is implemented in a few other classes.  Scripting does not
seem used at all, and anyone who did can easily write a wrapper that does
the same thing.

Deprecated *Proxy collections.

The only place proxies were used in the library was in swing.ListView, and
that was easy to change to a lazy val.

Proxy itself is used in ScalaNumberProxy and such, so it was left
undeprecated.

Deprecated Synchronized* traits from collections.

Synchronizability does not compose well, and it requires careful examination
of every method (which has not actually been done).

Places where the Scala codebase needs to be fixed (eventually) include:
  scala.reflect.internal.util.Statistics$QuantMap
  scala.tools.nsc.interactive.Global (several places)

Deprecated LinkedList (including Double- and -Like variants).

Interface is idiosyncratic and dangerously low-level.  Although some
low-level functionality of this sort would be useful, this doesn't seem
to be the ideal implementation.

Also deprecated the extractFirst method in Queue as it exposes LinkedList.
Cannot shift internal representations away from LinkedList at this time
because of that method.

Deprecated non-finality of several toX collection methods.

Improved documentation of most toX collection methods to describe what the
expectation is for their behavior.  Additionally deprecated overriding of
  - toIterator in IterableLike (should always forward to iterator)
  - toTraversable in TraversableLike (should always return self)
  - toIndexedSeq in immutable.IndexedSeq (should always return self)
  - toMap in immutable.Map (should always return self)
  - toSet in immutable.Set (should always return self)

Did not do anything with IterableLike.toIterable or Seq/SeqLike.toSeq since
for some odd reason immutable.Range overrides those.

Deprecated Forwarders from collections.

Forwarding, without an automatic mechanism to keep up to date with changes
in the forwarded class, is inherently unreliable.  Absent a mechanism to
keep current, they're deprecated.  ListBuffer is the only class in the
collections library that uses forwarders, and that functionality can be
rolled into ListBuffer itself.

Deprecating immutable set/map adaptors.

They're a bad idea (barring compiler support) for the same reason that all
the other adaptors are a bad idea: they get out of date and probably have a
variety of performance bugs.

Deprecated inheritance from leaf classes in immutable collections.

Inheriting from leaf-classes in immutable collections is rarely a good idea
since whenever you use any interesting collections method you'll revert to
the original class.  Also, the methods are often designed to work with only
particular behavior, and an override would be difficult (at best) to make
work.  Fortunately, people seem to have realized this and there are few to
no cases of people extending PagedSeq and TreeSet and the like.

Note that in many cases the classes will become sealed not final.

Deprecated overriding of methods and inheritance from various mutable
collections.

Some mutable collections seem unsuited for overriding since to override
anything interesting you would need vast knowledge of internal data
structures and/or access to private methods.  These include
  - ArrayBuilder.ofX classes.
  - ArrayOps
  - Some methods of BitSet (moved others from private to protected final)
  - Some methods of HashTable and FlatHashTable
  - Some methods of HashMap and HashSet (esp += and -= which just forward)
  - Some methods of other maps and sets (LinkedHashX, ListMap, TreeSet)
  - PriorityQueue
  - UnrolledBuffer

This is a somewhat aggressive deprecation, the theory being better to try it
out now and back off if it's too much than not attempt the change and be
stuck with collections that can neither be safely inherited nor have
implementation details changed.

Note that I have made no changes--in this commit--which would cause
deprecation warnings in any of the Scala projects available on Maven (at
least as gathered by Adriaan).  There are deprecation warnings induced
within the library (esp. for classes/traits that should become static) and
the compiler.  I have not attempted to fix all the deprecations in the
compiler as some of them touch the IDE API (but these mostly involved
Synchronized which is inherently unsafe, so this should be fixed
eventually in coordination with the IDE code base(s)).

Updated test checks to include new deprecations.

Used a higher level implementation for messages in JavapClass.