| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
SI-8266 Deprecate octal escapes in f-interpolator
|
| |
| |
| |
| |
| |
| | |
Also turns the f-interpolator into a migration
assistant by suggesting alternatives for the
standard escapes.
|
|\ \
| | |
| | | |
SI-6908 FlatHashTable and things that depend on it can't store nulls
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixed ParFlatHashTable to use entryToElem which correctly converts sentinels to nulls.
|
|\ \ \
| | | |
| | | | |
SI-8264 scala.collection.immutable.HashSet#- returns broken Set
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
Was an error in HashSet's handling of removal of an element when a HashTrieSet should turn into a HashSet1.
Also slightly modified HashMap's filter0 to more closely match HashSet (by adding the same comment).
|
|\ \ \
| | | |
| | | | |
SI-8188 NPE during deserialization of TrieMap
|
| |/ /
| | |
| | |
| | | |
The writer was using the constructor headf and ef instead of the internal vars hashingobj and equalityobj.
|
|\ \ \
| | | |
| | | | |
SI-6632 ListBuffer's updated accepts negative positions
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
Changed the behavior in SeqLike.updated (which would silently accept negatives and throw on empty.tail) to throw IndexOutOfBoundException.
Updated tests to verify the behavior in ListBuffer. Everything else SeqLike will come along for the ride.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Changed the implementation of iterator to be more robust to mutation of the underlying ListBuffer.
Added a test to make sure bug is gone.
Fixed an "unsafe" usage of ListBuffer.iterator in the compiler, and added a comment explaining the (new) policy for iterating over a changing ListBuffer.
The compiler now uses a synchronized-wrapped ArrayBuffer instead of ListBuffer, as that makes the (custom) units Iterator more natural to write (and avoids O(n) lookups).
|
|\ \
| | |
| | | |
SI-6736 Range.contains is wrong
|
| | |
| | |
| | |
| | |
| | |
| | | |
Operations are reasonable when they don't require indexing or conversion into a collection. These include head, tail, init, last, drop, take, dropWhile, takeWhile, dropRight, takeRight, span.
Tests added also to verify the new behavior.
|
| | |
| | |
| | |
| | | |
Removed once-used private method that was calculating ranges in error and corrected the contains method (plus improved performance).
|
|\ \ \
| |_|/
|/| | |
SI-5994 battling implicits for String.lines
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Deprecated ProcessBuilder's lines method and renamed it lineStream.
stream was another possibility, but that seemed more likely to cause conflicts.
streaming was also tried, but feedback was in favor of lineStream.
Also updated tutorial in ProcessBuilder.
I am sure this will break some tests, but because of the name conflict it's hard to be sure where they are. So Jenkins gets to find the problems for me.
Changed name to lineStream.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As reported on scala-user:
> Using `scala.Predef.readLine(text: String, args: Any*)`
> on Windows causes strange behavior. If I am leaving some
> part of `text` unforced to be flushed (say, "---\nEnter new
> expression >") then "Enter new expression >" flushed only
> after Enter press. Still, it works fine on Ubuntu and (seems like)
> on MacOS.
>
> My workaround is to force `java.lang.System.out` (that readLine
> depends on to write welcome string) to flush output like
> "---\nEnter new expression >\n".
|
|\ \
| | |
| | | |
Make the Abstract* classes public.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several weaknesses in the implementation converge and force multiply.
1) Type constructor inference is not persistent. During implicit search
it will give up after the first seen parent even if some deeper base type
(even another direct parent) would satisfy the search.
2) Type inference is not aware of access restrictions. Inferred types are
calculated with disregard for whether the inferred type is visible at
the point of inference. That means that package-private types - which may be
private for any number of good reasons, such as not wanting them to appear in
bytecode thus creating binary compatibility obligations - are not private.
There is no such thing as a qualified private type.
package p {
trait PublicInterface[T] { def foo(): Int }
private[p] trait ImplementationOnly[T] extends PublicInterface[T] { def foo(): Int = 1 }
class PublicClass extends ImplementationOnly[PublicClass]
}
package q {
object Test {
def f[A, CC[X]](xs: CC[A]): CC[A] = xs
def g = f(new p.PublicClass) // inferred type: p.ImplementationOnly[p.PublicClass]
def h = g.foo()
// Bytecode contains:
// public p.ImplementationOnly<p.PublicClass> g();
// public int h();
// 0: aload_0
// 1: invokevirtual #30 // Method g:()Lp/ImplementationOnly;
// 4: invokeinterface #33, 1 // InterfaceMethod p/ImplementationOnly.foo:()I
// 9: ireturn
}
}
3) The trait encoding leads to a proliferation of forwarder methods, so much so that
1.5 Mb of bytecode was taken off of the standard library size by creating abstract classes
which act as central mixin points so that leaf classes can inherit some methods the
old fashioned way rather than each receiving their own copy of every trait defined method.
This was done for 2.10 through the creation of the Abstract* classes, all of which were
given reduced visibility to keep them out of the API.
private[collection] class AbstractSeq extends ...
This achieved its intended goal very nicely, but also some unintended ones.
In combination with 1) above:
scala> val rand = new scala.util.Random()
rand: scala.util.Random = scala.util.Random@7f85a53b
// this works
scala> rand.shuffle(0 to 5)
res1: scala.collection.immutable.IndexedSeq[Int] = Vector(4, 0, 1, 2, 5, 3)
// and this doesn't! good luck reasoning that one out
scala> rand.shuffle(0 until 5)
<console>:9: error: Cannot construct a collection of type scala.collection.AbstractSeq[Int]
with elements of type Int based on a collection of type scala.collection.AbstractSeq[Int].
rand.shuffle(0 until 5)
^
// Somewhat comically, in scala 2.9 it was flipped: to failed (differently), until worked.
scala> scala.util.Random.shuffle(0 to 5)
<console>:8: error: type mismatch;
found : scala.collection.immutable.Range.Inclusive
required: ?CC[?T]
scala> scala.util.Random.shuffle(0 until 5)
res2: scala.collection.immutable.IndexedSeq[Int] = Vector(4, 3, 1, 2, 0)
In combination with 2) above:
scala> def f[A, CC[X]](xs: CC[A]): CC[A] = xs
f: [A, CC[X]](xs: CC[A])CC[A]
scala> var x = f(1 until 10)
x: scala.collection.AbstractSeq[Int] = Range(1, 2, 3, 4, 5, 6, 7, 8, 9)
// It has inferred a type for our value which it will not allow us to use or even to reference.
scala> var y: scala.collection.AbstractSeq[Int] = x
<console>:10: error: class AbstractSeq in package collection cannot be accessed in package collection
var y: scala.collection.AbstractSeq[Int] = x
^
// This one is a straight regression - in scala 2.9,
scala> var x = f(1 until 10)
x: scala.collection.immutable.IndexedSeq[Int] = Range(1, 2, 3, 4, 5, 6, 7, 8, 9)
Since 1) and 2) are essentially unfixable - at least by me - I propose
to ameliorate these regressions by attacking the symptoms at the leaves.
That means making all the Abstract* classes public - keeping in mind that
they must already be assumed to be in the binary compatibility footprint,
since they have been leaking throughout their existence. This only impacts
the inference of inaccessible collections types - it doesn't help with the
more serious issue with type inference.
|
|\ \
| | |
| | | |
SI-8215: Correcting typo and splitting a long sentence in MatchIterator doc
|
| |/
| |
| |
| | |
Follow-up to 9c0ca62
|
|/
|
|
|
|
| |
Changed logic to prevent mutation between hasNext and next from delivering invalid results.
Also fixed superscripts in scaladoc.
|
|\
| |
| | |
Improve ExecutionContext implicitNotFound and docs
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is not good practice to import a specific ExecutionContext
all over the place; we shouldn't recommend that. People should
allow callers to specify the context in most cases and only
import the context in some central location in their code.
While we are at it, add some more comprehensive docs to
ExecutionContext which will hopefully give people enough understanding
to make decisions about it.
|
|\ \
| | |
| | | |
SI-4997 deprecate StringLike.linesIterator for StringLike.lines
|
| | |
| | |
| | |
| | | |
Deprecated. lines is by far more consistent with the rest of the naming in the library.
|
| | |
| | |
| | |
| | |
| | | |
- `::.head` became a `val`; excessive accessor removed
- SerializationProxy moved to `object List`
|
|\ \ \
| | | |
| | | | |
SI-8215: Document IllegalStateExceptions thrown by uninitialized MatchIterator from Regex (review by @heathermiller)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
MatchIterator
See https://groups.google.com/forum/#!topic/scala-language/2T2wKVQiyVg
|
| |/ /
| | |
| | |
| | |
| | | |
The Content Hierarchy contains the same information, properly formatted.
See https://groups.google.com/d/msg/scala-language/2T2wKVQiyVg/3-iu19XSTxwJ
|
|\ \ \
| | | |
| | | | |
Grab bag of compiler optimizations
|
| |/ / |
|
|/ /
| |
| |
| |
| |
| | |
Changed tail-generation function to mutable and clear it after it's used to allow any captured memory to be freed once the tail has been generated.
(This is a case where a by-name parameter was used when a lazy val parameter was wanted instead. If we ever get lazy val parameters, we should switch to that.)
|
|/
|
|
|
|
| |
Altered getOrElseUpdate to be robust to the map changing out from under it as a result of calling the default value method. Side-effects FTW!
Made a comparable change in LongMap also, as it was also affected. And added a test to SetMapConsistencyTest.
|
|
|
|
|
|
| |
It's a language bug, but M[_] <: Foo[_] does not mean what
anyone who writes it believes that it means. You have to give
the type parameter a name, like M[X] <: Foo[X].
|
|\
| |
| | |
ListMap.tail is returning wrong result
|
| |
| |
| |
| |
| |
| |
| | |
Reverted the commit that introduced the bug, and modified HashMap to no
longer assume that tail is O(1).
Review by @Ichoran, @soc
|
|/
|
|
|
| |
We don't need to say everything twice, methods are already prefixed
with “read”.
|
|\
| |
| | |
SI-6253 HashSet should implement union
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implements of HashSet.union that reuses the two trees as much as
possible when calculating the union of two sets. This leads to significant
performance improvements as well as to much better structural sharing.
There is a comprehensive correctness test for union since there was not a single test
for HashSet.union before. In addition, there are some tests of the desirable
properties of the new implementation (structural sharing and efficiency
regarding calls of key.hashCode).
The other operations diff and intersect, which are conceptually very
similar to union, are also implemented along with comprehensive test cases
for both correctness and structural sharing.
Note that while it appears that there is some code duplication between the
three methods, they are sufficiently different that it is not possible
to merge them into one without sacrificing performance.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Int.MaxValue
Fixed by rewriting the entire logic for the count method. This is necessary because the old code was making all kinds of assumptions about what numbers were, but the interface is completely generic.
Those assumptions still made have been explicitly specified. Note that you have to make some or you end up doing a binary search, which is not exactly fast.
The existing routine is 10-20% slower than the old (broken) one in the worst cases. This seems close enough to me to not bother special-casing Long and BigInt, though I note that this could be done for improved performance.
Note that ranges that end up in Int ranges defer to Range for count. We can't assume that one is the smallest increment, so both endpoints and the step need to be Int.
A new JUnit test has been added to verify that the test works. It secretly contains an alternate BigInt implementation, but that is a lot slower (>5x) than Long.
|
|\
| |
| | |
SI-6196 - Set should implement filter
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the exact same algorithm as in SI-6196, with only slight
differences due to the two type arguments of HashMap.
Filter is tested by the new comparative collection test by @Ichoran, but
there is nevertheless a small correctness test in t6200 in addition to
tests of the new desirable behavior.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implements a version of filter and filterNot that reuses as much as
possible from the existing tree instead of building an entirely new one
like the builder-based filter does. This results in significant performance
improvements on average.
Adds a test of basic correctness of filter and filterNot as well as of the
desirable properties of the new filter implementation.
This is a collaboration between me and @Ichoran
|
|\ \
| | |
| | | |
SI-7544 StringContext.f docs update
|
| | |
| | |
| | |
| | |
| | | |
Correct the scaladoc to reflect how f"%" is handled,
namely, it's no longer taken as f"%%".
|
|\ \ \
| | | |
| | | | |
SI-6457 ImmutableSetFactory.empty results in StackOverflowError
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
ImmutableSetFactory relies upon empty to create its builder, which in turn relies upon its builder to create an empty. Added an emptyInstance method to hold the actual empty set (which also removes duplicated functionality for empty sets).
No test, as the original pattern:
object Factory extends collection.generic.ImmutableSetFactory[collection.immutable.Set] {}
no longer compiles. This should be verified by whoever checks this commit, but this kind of change is hard to revert by accident. No reason to waste resources checking it forevermore.
|
|\ \ \ \
| | | | |
| | | | | |
Quasi-comprehensive BigDecimal soundness/correctness fix.
|