SI-7502 removing non-existent element from ListMap returns same map.

Current imperative version constructs a new ListMap regardless of
the fact the map doesn't contain the element. Replace it with the
tail-recursive variant that conserves. Also replace some usages with
the invariant now held.
SI-7088 Array crasher in erasure.

The usual business where half our pattern matches are missing
half the necessary cases.
SI-7474 Parallel collections: End the exception handling madness

"What's wrong with an API which non-deterministically returns either
type A or type B(Set(A, ...))?"

This is pretty much what the exception handling behavior of the
parallel collections does: If exceptions of type A occur, either an
exception of type A or an exception of type B, wrapping multiple
exceptions of A's, is returned.

This behavior is incredibly broken and so unintuitive, that even
people writing tests don't handle it correctly, as seen in test
files/run/t5375.scala.

Concerning “non-deterministic”:
How many exceptions are observed before the operation is aborted
depends on the machine, the available cores and hyper-threading,
the operating system, the threadpool implementation and
configuration, the size of the collection and the runtime itself.

In fact, files/run/t5375.scala can be made to fail reproducible
on both jdk7u and Avian, if we run on a single-core machine
like in a virtual machine.

With this change, we just pass the "first" exception which occurs.

This is
- consistent with the behaviour of sequential collections,
- doesn't require users to know more about parallel collections
than they already do ("elements might be processed out of order"),
- in line with what Java 8 does.

“Why don't we wrap everything in CompositeThrowables?”
Even consistently returning CompositeThrowable doesn't make much
sense (because we have fail-fast behaviour and don't wait until
all tasks have finished or have thrown an exception).
Therefore, there is no useful semantic in having a
CompositeThrowable which returns "some" exceptions.

I have done extensive research into C#'s approach (which is very
similar to what Scala did until now, but even more messy) and
the key observation from asking multiple C# developers is that
not a single one had understood how PLINQ handled exceptions or
could describe the semantics of it.

As a consequence, either
a) gather and return all exceptions in a CompositeThrowable or
b) just return one, unwrapped,
instead of non-deterministically wrapping a non-deterministic
number of exceptions into a completely unrelated wrapper type.

Considering that changing the parallel collection semantics in
such a profound way as described in a) is out of question, b)
is chosen.

As soon as Scala targets Java > 7 Throwable#addSurpressed can be
used to add further exceptions to the one which gets returned.
This would allow passing more information to the caller without
compromising the simplicity of the API.
Merge pull request #2579 from vigdorchik/list_map

SI-7502 removing non-existent element from ListMap leaves it unchaged.
Merge pull request #2563 from soc/SI-7474

SI-7474 Parallel collections: End the exception handling madness
SI-7399 : Take scala.concurrent.context.maxThreads into account

This change fixes the bug whereby specifiying maxThread as a property
has no effect. A small refactoring is applied in the process.
Merge pull request #2424 from rjolly/si-7399

SI-7399 : Take scala.concurrent.context.maxThreads into account
SI-6309 Test case for early-init / private[this] crasher.

This has worked since 98daf03, "Overhauled local/getter/setter name logic.".
Revert "SI-6039 Harden against irrelevant filesystem details"

This reverts commit b0758f5cb9d966b940933d48bdbb45d17a80de66.

This commit sent startup time through the roof, at least
in some circumstances (it is presumably related to one's
current working directory.)
Merge pull request #2614 from paulp/pr/revert-fs

Revert "SI-6039 Harden against irrelevant filesystem details"
Merge pull request #2592 from paulp/issue/7088

SI-7088 Array crasher in erasure.
Finalized math.E and math.Pi.

Without this treatment these constants will not be inlined
or folded, bloating bytecode and inhibiting optimization.
Marking them @inline doesn't have any additional effect, but
I did it to futurize them in light of SI-7542.
Merge pull request #2618 from paulp/pr/final-in-package-object

Finalized math.E and math.Pi.
Merge pull request #2613 from retronym/ticket/6309

SI-6309 Test case for early-init / private[this] crasher.
an ICode InvokeStyle can now answer whether it isSuper
new bytecode emitter, GenBCode, for now under a flag

GenBCode is a drop-in replacement for GenASM with several advantages:

  - faster: ICode isn't necessary anymore.
    Instead, the ASTs delivered by CleanUp (an expression language)
    are translated directly into a stack-language (ASM Tree nodes)

  - future-proofing for Java 8 (MethodHandles, invokedynamic).

  - documentation included, shared mutable state kept to a minimum,
    all contributing to making GenBCode more maintainable
    than its counterpart (its counterpart being GenICode + GenASM).

A few tests are modified in this commit, for reasons given below.

(1) files/neg/case-collision

    Just like GenASM, GenBCode also detects output classfiles
    differing only in case. However the error message differs
    from that of GenASM (collisions may be show in different order).
    Thus the original test now has a flags file containing -neo:GenASM
    and a new test (files/neg/case-collision2) has been added
    for GenBCode. The .check files in each case show expected output.

(2) files/pos/t5031_3

    Currently the test above doesn't work with GenBCode
    (try with -neo:GenBCode in the flags file)
    The root cause lies in the fix to
    https://issues.scala-lang.org/browse/SI-5031
    which weakened an assertion in GenASM
    (GenBCode keeps the original assertion).
    Actually that ticket mentions the fix is a "workaround"

(3) files/run/t7008-scala-defined

    This test also passes only under GenASM and not GenBCode,
    thus the flags file. GenASM turns a bling eye to:

      An AbstractTypeSymbol (SI-7122) has reached the bytecode emitter,
      for which no JVM-level internal name can be found:
      ScalaClassWithCheckedExceptions_1.E1

    The error message above (shown by GenBCode) highlights
    there's no ScalaClassWithCheckedExceptions_1.E1 class,
    thus shouldn't show up in the emitted bytecode
    (GenASM emits bytecode that mentions the inexistent class).
two bytecode tests atune with bytecode by GenASM
GenBCode on by default