| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \
| |/
|/| |
Upgrade to jline2 2.14.3
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now that we use a release of JLine that includes the fix for:
https://github.com/jline/jline2/issues/208
We no longer need to the workaround introduced in 7719a3c.
Screencast of the still-fixed behaviour:
http://recordit.co/5pzh9OhlQv.gif
(cherry picked from commit 6871bccae321a04bea28144945c6afa4b6276905)
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cherry-picked 365ac03 (and bumped from 2.14.1 to 2.14.3)
Motivated by the improvements to multi-byte character handling.
Screencast showing the reported bug is fixed:
http://g.recordit.co/ie1Z367NUl.gif
Here's the changelog since JLine 2.12.1:
https://github.com/jline/jline2/compare/jline-2.12.1...jline-2.14.3
I needed to disable a new, on-by-default feature in JLine so that
it didn't add a " " after completing the token `equals` in
`foo.equa<TAB>`.
|
|\
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
[backport] Hash table getOrElseUpdate and indexing
|
| | |
| | |
| | |
| | | |
(cherry picked from commit 26c87f1af4cac782911500d6b143681ecdcef8ad)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes https://issues.scala-lang.org/browse/SI-10049
Since `groupBy` uses this method extensively and suffered a measurable slowdown in `2.12.0`, this modification restores (and exceeds) its original speed.
---
included benchmarks:
(`ns/op` → smaller is better)
`before (2.12.0):`
```java
Benchmark (size) Mode Cnt Score Error Units
s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 865.693 ± 7.869 ns/op
s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 3095.657 ± 56.438 ns/op
s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 28247.005 ± 470.513 ns/op
s.c.mutable.HashMapBenchmark.get 10 avgt 20 679.448 ± 11.809 ns/op
s.c.mutable.HashMapBenchmark.get 100 avgt 20 7240.178 ± 61.734 ns/op
s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95725.127 ± 2373.458 ns/op
s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 836.561 ± 20.085 ns/op
s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 7891.368 ± 56.808 ns/op
s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 97478.629 ± 1782.497 ns/op
s.c.mutable.HashMapBenchmark.put 10 avgt 20 243.422 ± 2.915 ns/op
s.c.mutable.HashMapBenchmark.put 100 avgt 20 5810.927 ± 60.054 ns/op
s.c.mutable.HashMapBenchmark.put 1000 avgt 20 82175.539 ± 1690.296 ns/op
```
`after:`
```java
Benchmark (size) Mode Cnt Score Error Units
s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 627.007 ± 9.718 ns/op
s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2086.955 ± 19.042 ns/op
s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 19515.234 ± 173.647 ns/op
s.c.mutable.HashMapBenchmark.get 10 avgt 20 683.977 ± 11.843 ns/op
s.c.mutable.HashMapBenchmark.get 100 avgt 20 7345.675 ± 41.092 ns/op
s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95085.926 ± 1702.997 ns/op
s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 503.208 ± 2.643 ns/op
s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5526.483 ± 28.262 ns/op
s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 69265.900 ± 674.958 ns/op
s.c.mutable.HashMapBenchmark.put 10 avgt 20 252.481 ± 7.597 ns/op
s.c.mutable.HashMapBenchmark.put 100 avgt 20 5708.034 ± 110.360 ns/op
s.c.mutable.HashMapBenchmark.put 1000 avgt 20 82051.378 ± 1432.009 ns/op
```
i.e. for the given benchmark conditions `~40%` faster `groupBy` and `getOrElseUpdate`
(cherry picked from commit b67ca7dc6bb84758f9c9f64d68b0b11c20995aa0)
|
| | |
| | |
| | |
| | | |
(cherry picked from commit bc912230129d68466474bcc6c99356b44f65c3c2)
|
| | |
| | |
| | |
| | | |
(cherry picked from commit 7952525e7119282ec8308a0076db54923f95dc21)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
(`ops/s`, smaller is better)
`Before (9c5d3f8)`:
```scala
[info] # Run complete. Total time: 00:08:15
[info]
[info] Benchmark (size) Mode Cnt Score Error Units
[info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 645.594 ± 9.435 ns/op
[info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2084.216 ± 37.814 ns/op
[info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 19878.481 ± 262.404 ns/op
[info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 689.941 ± 5.850 ns/op
[info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7357.330 ± 45.956 ns/op
[info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95767.200 ± 1550.771 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 509.181 ± 2.683 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5563.301 ± 32.335 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 71965.365 ± 1809.738 ns/op
[info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 247.270 ± 3.972 ns/op
[info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5646.185 ± 106.172 ns/op
[info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 81303.663 ± 954.938 ns/op
```
`Changed modulo to bitwise and in hash calculation (4c729fe)`:
```scala
[info] Benchmark (size) Mode Cnt Score Error Units
[info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 631.291 ± 9.269 ns/op
[info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2077.885 ± 59.737 ns/op
[info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 15458.278 ± 317.347 ns/op
[info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 678.013 ± 4.453 ns/op
[info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7258.522 ± 76.088 ns/op
[info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 94748.845 ± 1226.120 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 498.042 ± 5.006 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5243.154 ± 110.372 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 68194.752 ± 655.436 ns/op
[info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 257.275 ± 1.411 ns/op
[info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5318.532 ± 152.923 ns/op
[info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 79607.160 ± 651.779 ns/op
```
`Optimized HashTable.index (6cc1504)`:
```scala
[info] Benchmark (size) Mode Cnt Score Error Units
[info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 616.164 ± 4.712 ns/op
[info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2034.447 ± 14.495 ns/op
[info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 14712.164 ± 119.983 ns/op
[info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 679.046 ± 6.872 ns/op
[info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7242.097 ± 41.244 ns/op
[info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95342.919 ± 1521.328 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 488.034 ± 4.554 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 4883.123 ± 59.268 ns/op
[info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 65174.034 ± 496.759 ns/op
[info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 267.983 ± 1.797 ns/op
[info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5097.351 ± 104.538 ns/op
[info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 78772.540 ± 543.935 ns/op
```
Summary, i.e. the effect of this PR, according to the benchmarks:
* `groupBy` has a `~35%` speedup
* `get` didn't change
* `getOrElseUpdate` has a `~10%` speedup
* `put` has a `~3%` speedup
Note: caching the `exponent` to a local private field (`Byte` or `Int`) didn't have any performance advantage (only a minor slowdown was measured, possibly because it's accessed via an interface now)
(cherry picked from commit a5014447861a5678c8b595e235019bb8fec098a7)
|
| | |
| | |
| | |
| | | |
(cherry picked from commit 9a2486087a9739108265e7830ebaa96373605d02)
|
|/ / |
|
|\ \
| | |
| | | |
Cleanup in aisle patmat
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Hash consing of trees within pattern match analysis was broken, and
considered `x1.foo#1` to be the same tree as `x1.foo#2`, even though
the two `foo`-s referred to different symbols.
The hash consing was based on `Tree#correspondsStructure`, but the
predicate in that function cannot veto correspondance, it can only
supplement the default structural comparison.
I've instead created a custom tree comparison method for use in
the pattern matcher that handles the tree shapes that we use.
(cherry picked from commit 79a52e6807d2797dee12bab1730765441a0e222d)
|
| | |
| | |
| | |
| | | |
While investigating https://github.com/scala/scala-dev/issues/251
|
| |/
| |
| |
| | |
While investigating https://github.com/scala/scala-dev/issues/251
|
|\ \
| |/
|/| |
Fix documentation of immutable.Queue
|
|/
|
| |
`enqueue` appends elements to the `Queue`, it doesn't prepend them.
|
|\
| |
| | |
Fix spec links to `07-implicits.html`
|
| |
| |
| |
| |
| | |
The file referenced by the current links actually exists under
http://www.scala-lang.org/files/archive/spec/2.11/ but with a different
design than the rest. It seems to be left over from an older version.
|
|\ \
| | |
| | | |
Use ClassTag instead of Manifest in AssertUtil.assertThrows.
|
|/ /
| |
| |
| |
| | |
This allows it to work in Scala.js, which supports `ClassTag`s but
not `Manifest`s.
|
|\ \
| | |
| | | |
SI-3236 constant types for literal final static java fields
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For example, public static final byte b = 127 is allowed, but 128 is
not.
Also factor out a method that parses a literal. It could be used to
parse annotations (and their literal arguments) in Java sources.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since we don't parse Java expressions, fields of Java classes coming
from source files never have constant types. This prevents using
static java fields in annotation arguments in mixed compilation
This PR assigns constant types to final static java fields if the
initializer is a simple literal.
|
|\ \ \
| | | |
| | | | |
SI-9834 Improve error on failed op=
|
| | | | |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If rewriting `x += y` fails to typecheck, emit error messages
for both the original tree and the assignment.
If rewrite is not attempted because `x` is a val, then say so.
The error message at `tree.pos` is updated with the additional advice.
SI-8763 Crash in update conversion
When there are already errors, don't attempt mechanical rewrites.
|
|\ \ \
| | | |
| | | | |
Upgrade MiMa to 0.1.13
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
fix eBNF error by removing wrong closing brace
|
| |/ / / |
|
|/ / /
| | |
| | | |
SI-10086 NumericRange.min|max with custom Integral
|
|\ \ \
| | | |
| | | | |
upgrade MiMa to 0.1.12
|
|/ / /
| | |
| | |
| | |
| | | |
dogfooding the latest. upgrading all the way from 0.1.8 -- there have
been a bunch of improvements since then.
|
| | |
| | |
| | |
| | | |
This fixes the vertical bar problem on Chrome
(https://github.com/mathjax/MathJax/issues/1300);
|
|\ \ \
| | | |
| | | | |
Improve performance of REPL autocompletion
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The code used to fuzzily match, e.g, `declasses` with `getDeclaredClasses`
was exploring fruitless parts of the search space. The enclosed test
case was hanging the REPL.
This commit improves this by performing a prefix match of the unconsumed input
against the current chunk of the candidate before exploring the `inits`.
Fixes scala/scala-dev#271
|
|\ \ \
| |/ /
|/| | |
Use https links to JS and CSS in the spec when serving from https
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The spec is published on a server that supports https
(https://www.scala-lang.org/files/archive/spec/2.11/) and this comes up
as the default in search results (as it should) but the link to
MathJAX is hardcoded to http, which prevents any web browser that cares
about security from loading it.
This commit changes the links to MathJAX and to the Highlight.js
stylesheet to be scheme-relative (like the link to JQuery already was).
|
|\ \
| | |
| | | |
SI-10037 ASR/LSR switched in ICodeReader
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Noticed when inlining from a class file.
The test doesn't work because inlining fails with
bytecode unavailable due to:
```
scala.reflect.internal.MissingRequirementError: object X in compiler mirror not found.
```
|
|\ \ \
| |/ /
|/| | |
move to latest Akka 2.3.x release
|
| | |
| | |
| | |
| | |
| | | |
Akka 2.3.16 was released in October 2016:
http://akka.io/news/2016/10/30/akka-2.3.16-released.html
|
|\ \ \
| | | |
| | | | |
don't mass-delete old nightlies at release time
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
as happened with 2.12.0, for gory details see
https://github.com/scala/scala-dev/issues/257
fix suggested by Stefan Zeiger
|
|\ \ \
| | | |
| | | | |
Silence SBT logging about macros and incremental compilation.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since upgrading to SBT 0.13.12, clean builds have incurred warnings like:
Because JavaMirrors.scala contains a macro definition, the following
dependencies are invalidated unconditionally: ....
This commit disables this behaviour of the SBT incremental compiler in
the library and reflect projects, as these aren't regular macros (the
macro implementations are hard coded in the compiler in `FastTrack`)
so the new behaviour isn't actually improving correctness of inc.
compilation.
|