| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Merge 2.10.x to 2.11.x
|
| |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/library/scala/concurrent/Promise.scala
test/files/jvm/future-spec/PromiseTests.scala
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Calling `completeWith` when the `DefaultPromise` is already completed,
leads to callbacks not being properly executed.
This happened because `Future.InternalCallbackExecutor` extends
`BatchingExecutor`[1] which assumes `unbatchedExecute` to be async,
when in this case it is sync, and if there is an exception thrown
by executing the batch, it creates a new batch with the remaining
items from the current batch and submits that to `unbatchedExecute`
and then rethrows, but if you have a sync `unbatchedExecute`, it will
fail since it is not reentrant, as witnessed by the failed `require`
as reported in this issue.
This commit avoids problem by delegating `completeWith` to
`tryComplete`, which has the effect of using `onComplete` +
`tryComplete` i.s.o. `complete`, which means that when it fails
(because of a benign race condition between completers) it won't
throw an exception.
It has been tested by the minimized reproducer.
[1] Actually, in the 2.10.x branch where this patch is starting out,
"The BatchingExecutor trait had to be inlined into
InternalCallbackExecutor for binary compatibility.". This comment
will be more literally correct in the context of 2.11.x and beyond
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Backport the doc with two material changes:
1. need to use Groups to extract from Match,
so say that in lieu of the 2.11 advice that
the Regex instance can be used without
recomputing the match;
2. and relatedly, in 2.10 there is no secondary
constructor, so the doc for group names is
moved back up to the class doc.
Original doc update on PR #3923 was:
0e26910372d349c6ff7bbaa17fc8fe0bf568c5fe
f98c53cb03f800b3d790f3866ab90f827fd131f5
|
| | |\
| | | |
| | | | |
[backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Backport of scala/scala-parser-combinators@91584dc.
---
Starting with 1.7.0_06 [1], String.substring no longer reuses the internal
char array of the String but make a copy instead. Since we call
subSequence twice for *every* input character, this results in horrible
parse performance and GC.
With the benchmark from the (duplicate) ticket SI-8542, I get:
BEFORE:
parseAll(new StringReader(String))
For 100 items: 49 ms
For 500 items: 97 ms
For 1000 items: 155 ms
For 5000 items: 113 ms
For 10000 items: 188 ms
For 50000 items: 1437 ms
===
parseAll(String)
For 100 items: 4 ms
For 500 items: 67 ms
For 1000 items: 372 ms
For 5000 items: 5693 ms
For 10000 items: 23126 ms
For 50000 items: 657665 ms
AFTER:
parseAll(new StringReader(String))
For 100 items: 43 ms
For 500 items: 118 ms
For 1000 items: 217 ms
For 5000 items: 192 ms
For 10000 items: 196 ms
For 50000 items: 1424 ms
===
parseAll(String)
For 100 items: 2 ms
For 500 items: 8 ms
For 1000 items: 16 ms
For 5000 items: 79 ms
For 10000 items: 161 ms
For 50000 items: 636 ms
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6924259
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Errant `self.length` changed to `length`.
No tests; found and tested by collections-laws.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Added `.seq` in two essential places so that a parallel collection passed as an argument won't mess up side-effecting sequential computations in `List.flatMap` and `GenericTraversableTemplate.transpose` (thanks to retronym for finding the danger spots).
Tests that `.seq` is called by constructing a `GenSeq` whose `.seq` disagrees with anything non-`.seq` (idea & working implementation from retronym).
Also updates the `.seq` test for `Vector#++` to use the new more efficient method.
|
|\ \ \
| | | |
| | | | |
Optimization of IterableLike.scala
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Changed takeRight to have two tighter loops instead of one with a conditional. See about 10% performance improvement.
Other changes were (surprisingly, in some cases) not a win. Overall, IterableLike is pretty well optimized.
|
|\ \ \ \
| | | | |
| | | | | |
SI-8917 collection.mutable.BitSet's &= operator doesn't clear end
|
| |/ / /
| | | |
| | | |
| | | | |
Made &= run to the end of its own bitset, ignoring the size of what it's &-ing with (which is exactly what you want for &=).
|
|\ \ \ \
| | | | |
| | | | | |
Fix SI-7943 -- make `TrieMap.getOrElseUpdate` atomic.
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Override `getOrElseUpdate` method in `TrieMap`.
The signature and contract of this method corresponds closely to the
`computeIfAbsent` from `java.util.concurrent.ConcurrentMap`.
Eventually, `computeIfAbsent` should be added to
`scala.collection.concurrent.Map`.
Add tests.
Review by @Ichoran
|
|\ \ \ \
| | | | |
| | | | | |
Simpler & Scala.js-friendly `ClassTag.unapply`
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Inline overloaded calls to `unapply`, so we can get rid of them in 2.13.
Note that theres a lot of `box(unbox(x))` going on behind the scenes.
Is this needed?
|
| |/ / /
| | | |
| | | |
| | | |
| | | | |
Use `j.l.Class.isInstance` for Scala.js, so that `unapply`
works correctly when referencing raw JavaScript classes.
|
|\ \ \ \
| | | | |
| | | | | |
SI-9116 Set.subsets has a param list
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now both of the overloaded variants have a parameter list.
This seems to make type inference happier. Or it makes someone
happier.
The user is unaware whether `subsets()` takes a default arg.
But happily, empty application still kicks in.
|
|\ \ \ \
| | | | |
| | | | | |
SI-7660: Document behaviour of Set#++ for duplicate elements
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Updated documentation of + and ++ in SetLike to explicitly state that duplicate elements
are not added to the set.
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Generate alphanumeric values by taking random element of string
containing all alphanumerics.
Instead of generating nextPrintableChar then filtering for
alphanumerics, we can just take from a string containing all
alphanumerics. This provides a significant performance improvement.
|
|\ \ \ \
| | | | |
| | | | | |
SI-9095 Memory leak in LinkedHasMap and LinkedHashSet
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The clear() method in scala.collection.mutable.LinkedHashSet and
scala.collection.mutable.LinkedHashMap does not set lastEntry to null.
In result it holds a reference to an object that was removed from the
collection.
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
SI-8988 Escaping character in StringLike.split(c) is slow
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
optimized String.split code path
Escaping a char when calling split is slow. We end up compiling a
Pattern to simply match a character literal.
Instead, we just use an loop with indexOf to construct our resulting
Array.
Current speed up over old behaviour is about 12-1
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Patch 1 - Scala doc improved
|
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Reading this doc (having no code) can be ambiguous.
updated scala doc (overloaded sliding method)
Step is a method parameter and must be always given explicit, so info about default value is wrong.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-8976 MutableList.tail.iterator.size is length
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The previous behavior was to iterate over the mutated
list of arbitrary length. The previous iteration of
the iterator would also iterate the terminal element
of the list without halting.
This is fixed by capping the length of iterator.
That is OK because mutating the list by adding to it during
iteration is not recommended.
For good measure, the exhausted iterator does not hold
a reference to any remaining tail.
A test is added that will no doubt be superseded by the QCC tests.
(Quasi-Comprehensive Collections.)
The test just checks that the extra tail is not strongly
reachable from the iterator. If the garbage collector happens
to kick in and determine that the object is weakly reachable,
then the check terminates early.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-7770 mutable.BitSet.toImmutable isn't immutable
|
| | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | | |
Mark method as deprecated due to it not providing the expected result,
while fixing it will break existing code.
|
|\ \ \ \ \ \
| |_|_|/ / /
|/| | | | | |
Document concurrent package object
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
SI-9072 Vector ++ concatenation of parallel collection cause inconsisten...
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
results
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-5817: Add header to language.scala and languageFeature.scala
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
These two files were missing headers.
There is other work on-going to automate updating of the headers, but
that likely won't crossover with this.
|
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As diagnosed by the reporter, we needed additional overrides
due to the way these orderings are implemented.
I've added tests to show other methods and other orderings
are working correctly.
After writing that, I found a scalacheck test related to
NaN handling that also covers `Ordering`. I had to correct
the assertion in the tests of `reverse.{min,max}`.
|
|\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | | |
Fix many typos in docs and comments
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This commit corrects many typos found in scaladocs, comments and
documentation. It should reduce a bit number of PRs which fix one
typo.
There are no changes in the 'real' code except one corrected name of
a JUnit test method and some error messages in exceptions. In the case
of typos in other method or field names etc., I just skipped them.
Obviously this commit doesn't fix all existing typos. I just generated
in IntelliJ the list of potential typos and looked through it quickly.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fix scaladoc OutpuStream typo
|
| |/ / / / / / |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
- Enumeration#withName in case of a failed approach to resolve the
Enumeration value fails with a meaningless NoSuchElementException.
Would be nice to know what exactly is not found
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
SI-8538 Test or example for Source.report
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | | |
Scaladoc for report extension point.
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
insert and insertAll were slower than their java equivalents by factors
of 5 and 10 respectively.
Benchmark code was provided here:
https://gist.github.com/rklaehn/3e9290118fcf63d1feae
We are using a toList to the source Traversable
Then doing a length and a copy on that collection.
By using an array, we can make use of faster methods.
Managed to get the ratios down to 1.5 and 1.5 respectively.
In addition to this, I think we should consider breaking insert into 2
separate methods, one for a single item and one for a collection. The
varags version is very expensive when a single item is being inserted.
@phaller @axel22
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Added `idx >= 0` tests for `SeqViewLike#Sliced` `apply` and `mutable.IndexedSeqViewLike#Sliced` `unapply`. Now you get `IndexOutOfBoundsException`s as you should.
No tests; this was found by collections-laws and will be tested by them. (Exact variants in bug report were tested in the REPL.)
|
|\ \ \ \
| | | | |
| | | | | |
SI-9000 equals for immutable collections should check identity
|