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.
Make all numeric coercions explicit.

Optimistically, this is preparation for a day when we don't
let numeric types drift with the winds. Even without the optimism
it's a good idea. It flushed out an undocumented change in
the math package object relative to the methods being forwarded (a
type is widened from what is returned in java) so I documented
the intentionality of it.

Managing type coercions manually is a bit tedious, no doubt,
but it's not tedious enough to warrant abandoning type safety
just because java did it.
Merge pull request #2593 from paulp/pr/no-numeric-widen

Make all numeric coercions explicit.
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
Almost-fix for SI-3452.

At this commit ant test-opt has two test failures:

  test/files/pos/javaReadsSigs [FAILED]
  test/files/run/t4238 [FAILED]

Fix for wrong bytecode in forwarders.

This took me so long to figure out I can't even tell you. Partly because
there were two different bugs, one which only arose for trait forwarders
and one for mirror class forwarders, and every time I'd make one set
of tests work another set would start failing. The runtime failures
associated with these bugs were fairly well hidden because you usually
have to go through java to encounter them: scala doesn't pay that much
attention to generic signatures, so they can be wrong and scala might still
generate correct code. But java is not so lucky.

Bug #1)

During mixin composition, classes which extend traits receive forwarders
to the implementations. An attempt was made to give these the correct
info (in method "cloneBeforeErasure") but it was prone to giving
the wrong answer, because: the key attribute which the forwarder
must capture is what the underlying method will erase to *where the
implementation is*, not how it appears to the class which contains it.
That means the signature of the forwarder must be no more precise than
the signature of the inherited implementation unless additional measures
will be taken.

This subtle difference will put on an unsubtle show for you in test
run/t3452.scala.

  trait C[T]
  trait Search[M] { def search(input: M): C[Int] = null }
  object StringSearch extends Search[String] { }
  StringSearch.search("test");  // java
  // java.lang.NoSuchMethodError: StringSearch.search(Ljava/lang/String;)LC;

Before/after this commit:

  <   signature                                search  (Ljava/lang/String;)LC<Ljava/lang/Object;>;
  ---
  >   signature                                search  (Ljava/lang/Object;)LC<Ljava/lang/Object;>;

Bug #2) The same principle is at work, at a different location.
During genjvm, objects without declared companion classes
are given static forwarders in the corresponding class, e.g.

  object Foo { def bar = 5 }

which creates these classes (taking minor liberties):

  class Foo$ { static val MODULE$ = new Foo$ ; def bar = 5 }
  class Foo  { static def bar = Foo$.MODULE$.bar }

In generating these, genjvm circumvented the usual process whereby one
creates a symbol and gives it an info, preferring to target the bytecode
directly. However generic signatures are calculated from symbol info
(in this case reusing the info from the module class.) Lacking even the
attempt which was being made in mixin to "clone before erasure", we
would have runtime failures of this kind:

  abstract class Foo {
    type T
    def f(x: T): List[T] = List()
  }
  object Bar extends Foo { type T = String }
  Bar.f("");    // java
  // java.lang.NoSuchMethodError: Bar.f(Ljava/lang/String;)Lscala/collection/immutable/List;

Before/after this commit:

<   signature                                     f  (Ljava/lang/String;)Lscala/collection/immutable/List<Ljava/lang/String;>;
---
>   signature                                     f  (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/Object;>;

Closes SI-3452.