| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This reverts commit d540bf01fe4d9e5c56a68b0d3bada9d97af77e3f.
|
|
|
|
| |
This reverts commit eb5c51383a63c5c3420e53ef021607ff5fd20296.
|
|
|
|
| |
This reverts commit f24c2603d0acee5bcb6d5d80bf1e1a4645fa74f0.
|
|\
| |
| |
| | |
Include 828a892 Merge pull request #5753
|
| | |
|
|\ \
| | |
| | | |
Improving ScalaDoc for ExecutionContexts
|
| | | |
|
|\ \ \
| | | |
| | | | |
Fix typo in JavaConverters doc
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There is no such thing as scala.collection.mutable.concurrent.Map
error: object concurrent is not a member of package scala.collection.mutable
Introduced in 2908236a
|
|\ \ \ \
| |_|/ /
|/| | | |
Implement ListBuffer.isEmpty / nonEmpty / head efficiently
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Uses the extra length information to provide more
efficient implementations.
Evaluating these methods turns up with about 5-6% of akka-http
message parsing.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
until the spawned process exits neither
does it return its exit code.
|
|\ \ \ \
| |/ / /
|/| | | |
SI-10225 Either docs compile
|
| | | |
| | | |
| | | |
| | | | |
Per Seth.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
But without tut support, who knows.
Boy scout aligns stars and updates several
examples that didn't infer types in a way
that compiles.
|
| | | |
| | | |
| | | | |
It turned up in play profiling.
|
|\ \ \ \
| |/ / /
|/| | | |
Fix and improve Regex doc
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As reported by @djvulee, there was an error in
the example explaining the confusing behavior
of `MatchIterator`. It's really confusing.
|
|\ \ \ \
| |/ / /
|/| | | |
Improve the performance of Map4 to HashMap and Set4 to HashSet transitions
|
| |/ / |
|
|\ \ \
| | | |
| | | | |
SI-10187 Support mutation of mutable.HashMap in getOrElseUpdate
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Scala 2.12.1 included optimizations to `HashMape.getOrElseUpdate`
to avoid recomputing the index in the hash table when adding an
the element.
However, this index could be stale if the callback added elements
to the map and triggered a resize.
This commit checks that the table is unchanged before reusing
the index, restoring the 2.12.0 behaviour.
|
|\ \ \ \
| |_|/ /
|/| | | |
Further small HashTable optimizations
|
| |/ / |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
`scala.color` now has 3 states: `true`, `false` and `auto`
(the default). `auto` allows colors if not on windows and if the shell
is interactive (as in, both stdin and stdout are a tty).
The autodetect works as expected when run via SBT too, and it can always
be overriden on the CLI or via JAVA_OPTS.
|
|\ \ |
|
| |\ \
| | | |
| | | | |
Changing deprecation warning to lineStream
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The deprecation text of `ProcessBuilder.lines(log: ProcessLogger)` and `ProcessBuilder.lines_!(log: ProcessLogger) mentions to use the method `stream` and `stream_!` respectively. These methods do not exists.
The text has been changed to use `lineStream` and `lineStream_!` respectively.
|
| |\ \ \
| | | | |
| | | | | |
SI-10164 BitSet.tail zigs where it zagged
|
| | |/ /
| | | |
| | | |
| | | |
| | | | |
A cut/paste issue, an increment was held over from head,
which scans forward, to tail, which scans backward.
|
| |\ \ \
| | | | |
| | | | | |
SI-9519 removed the usecase section of the ++-method
|
| | | | | |
|
| |\ \ \ \
| | | | | |
| | | | | | |
SI-10177 Override lazy operations to preserve TrieMap's semantics
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Calling .iterator on a TrieMap gives a read-only snapshot. This then
extends to most inherited implementations written in terms of .iterator.
However, some inherited methods, such as .values, either defer the call
to .iterator or call it more than once. This results in subsequent
mutations to the original map being visible
I reviewed the inherited implementations from MapLike and found we
needed overrides of `values`, `keySet`, `filterKeys`, and `mapValues`.
Like `iterator`, these now create a read-only snapshot.
|
| |\ \ \ \
| | | | | |
| | | | | | |
SI-4700 The thrilling continuation to the infix type printing saga.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add ability to disable this via the @showAsInfix annotation.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
```
scala> import scala.annotation.infix
import scala.annotation.infix
scala> @infix class &&[T, U]
defined class $amp$amp
scala> def foo: Int && Boolean = ???
foo: Int && Boolean
```
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
Nuance doc for sliding
|
| | | |/ / /
| | |/| | |
| | | | | |
| | | | | | |
Attempt to clarify how final element is handled.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
during bootstrap, don't build scala-parser-combinators or -swing
|
| | |/ / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
I see no further reason to include them in the bootstrap process.
Adriaan agrees (in-person discussion).
note that the community build makes sure the modules still compile as
we make changes to Scala.
as for actually publishing scala-parser-combinators and scala-swing
when we make binary incompatible changes to Scala, I think it's fine
to consider that properly the job of the module maintainers, rather
than properly the job of this script. (if we want more automation
on that, we could make some elsewhere, keeping that concern separate
from actual bootstrapping concerns.)
scala-xml, scala-partest, and scalacheck (commented out at the moment)
remain in this script since they are all actually still part of the
bootstrapping picture.
fixes https://github.com/scala/scala-dev/issues/302 , so that
integrate-bootstrap will pass again (currently it fails, since
scala-parser-combinators merged Scala.js support)
|
|\ \ \ \ \ \
| | |_|_|_|/
| |/| | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We introduce a package-private superclass with the overridden
implementations. This is public at the bytecode level, so it needs
to be whitelisted.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
use Array block copy operations rather than builder/iterator
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Co-Authored-By: Jason Zaugg <jzaugg@gmail.com>
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`s.c.i.RedBlackTree.TreeIterator` uses a stack of nodes that need
to be processed later. This stack is implemented as an `Array`,
which is allocated with the maximum size that can possibly be
used, based on properties of red-black trees. This was added in
72ec0ac869a29fca9ea0d45a3f70f1e9e1babaaf. At the time, there was
no `iteratorFrom` method, and as the comment in that commit says,
the deepest nodes were never added to the stack, hence the final
`- 1` in computing the maximum stack size.
However, this changed with the introduction of `iteratorFrom` in
62bc99d3b20a7b37a977b19a6202cdac474eb5f6. The method `startFrom`
used to initialize the iterator at the right `start` node does
push the deepest nodes in some cases.
This internal bug got unnoticed because `pushNext` (originally
`pushPath`) has some error recovery in case the stack size got
miscalculated. This has performance impacts, though, since an
exception is thrown and caught.
More importantly, this error recovery mechanism does not work in
Scala.js, which considers `ArrayIndexOutOfBoundsException` to be
undefined behavior.
This commit fixes the stack size computation by simply removing
the `- 1` term. To minimize risks on Scala/JVM, the error recovery
mechanism is left untouched.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
monkey-mas/modify-ArrayBuilder-reusability-bug-2016-12-24
[Backport] Modify ArrayBuilder and WrappedArrayBuilder to be reusable
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As they're reusable in 2.12.x with this change[1], it'd be useful
to make them reusable in 2.11.x.
[1] https://github.com/scala/scala/commit/6eaae1b969b68ed3dc65a40613a8168b09246256
With this change, not only are they reusable but also we can avoid
mutation of previously created arrays.
Behaviour(Problem):
Actual behaviour before this modification is as follows;
<ArrayBuilder>
```
scala> import scala.collection.mutable.ArrayBuilder
import scala.collection.mutable.ArrayBuilder
scala> val builder = new ArrayBuilder.ofInt
builder: scala.collection.mutable.ArrayBuilder.ofInt = ArrayBuilder.ofInt
scala> builder ++= Vector.range(1, 17)
res0: builder.type = ArrayBuilder.ofInt
scala> val arr = builder.result()
arr: Array[Int] = Array(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
scala> builder.clear()
scala> builder += 100
res2: builder.type = ArrayBuilder.ofInt
scala> val arr2 = builder.result()
arr2: Array[Int] = Array(100)
scala> arr
res3: Array[Int] = Array(100, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
// arr should be Array(1, .., 16) but was unexpectedly mutated by `+=` operation
```
`arr` was mutated as follows;
1. `result` & `clear`
- `arr = elems`
- `size = 0`
2. `+=(100)`
- `ensureSize(0 + 1)`
=> `capacity < size || capacity == 0` is `false` as `capacity == 16`
and `size == 1`
- `elems(0) = 100` this is where `arr(0) = 100` was done because we
did not reallocate a new array for `elems` when calling `ensureSize`,
which should have happened.
- `size = 1`
3. `result`
- `mkArray(1)` gives us `arr2 = Array(100)`
<WrappedArrayBuilder>
We can observe almost the same mutation behaviour of ArrayBuilder.
```
scala> import scala.collection.mutable.WrappedArray
import scala.collection.mutable.WrappedArray
scala> import scala.collection.mutable.WrappedArrayBuilder
import scala.collection.mutable.WrappedArrayBuilder
scala> import scala.reflect.ClassTag
import scala.reflect.ClassTag
scala> val builder = new WrappedArrayBuilder(ClassTag.Int)
builder: scala.collection.mutable.WrappedArrayBuilder[Int] = scala.collection.mutable.WrappedArrayBuilder@56cbfb61
scala> builder ++= Vector.range(1, 17)
res0: builder.type = scala.collection.mutable.WrappedArrayBuilder@56cbfb61
scala> builder.result()
res1: scala.collection.mutable.WrappedArray[Int] = WrappedArray(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
scala> builder.clear()
scala> builder += 100
res3: builder.type = scala.collection.mutable.WrappedArrayBuilder@56cbfb61
scala> res1
res4: scala.collection.mutable.WrappedArray[Int] = WrappedArray(100, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)
scala> builder.result()
res5: scala.collection.mutable.WrappedArray[Int] = WrappedArray(100)
```
Solution:
We should reset `capacity` to `0` when calling `result` so that
`ensureSize(1)` calls `resize(16)`, which satisfies the property of Builder
reusability. Besides mutation of previously created arrays does not happen.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
(cherry picked from commit 26c87f1af4cac782911500d6b143681ecdcef8ad)
|