summaryrefslogtreecommitdiff
path: root/src/library
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3511 from som-snytt/issue/interp-octalAdriaan Moors2014-02-151-3/+8
|\ | | | | SI-8266 Deprecate octal escapes in f-interpolator
| * SI-8266 Deprecate octal escapes in f-interpolatorSom Snytt2014-02-111-3/+8
| | | | | | | | | | | | Also turns the f-interpolator into a migration assistant by suggesting alternatives for the standard escapes.
* | Merge pull request #3528 from Ichoran/issue/6908Adriaan Moors2014-02-151-4/+4
|\ \ | | | | | | SI-6908 FlatHashTable and things that depend on it can't store nulls
| * | Made ParFlatHashTableIterator private vars private[this].Rex Kerr2014-02-151-3/+3
| | |
| * | SI-6908 FlatHashTable and things that depend on it can't store nullsRex Kerr2014-02-131-1/+1
| | | | | | | | | | | | Fixed ParFlatHashTable to use entryToElem which correctly converts sentinels to nulls.
* | | Merge pull request #3527 from Ichoran/issue/8264Adriaan Moors2014-02-152-6/+7
|\ \ \ | | | | | | | | SI-8264 scala.collection.immutable.HashSet#- returns broken Set
| * | | SI-8264 scala.collection.immutable.HashSet#- returns broken SetRex Kerr2014-02-142-6/+7
| |/ / | | | | | | | | | | | | | | | 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).
* | | Merge pull request #3531 from Ichoran/issue/8188Adriaan Moors2014-02-141-2/+2
|\ \ \ | | | | | | | | SI-8188 NPE during deserialization of TrieMap
| * | | SI-8188 NPE during deserialization of TrieMapRex Kerr2014-02-141-2/+2
| |/ / | | | | | | | | | The writer was using the constructor headf and ef instead of the internal vars hashingobj and equalityobj.
* | | Merge pull request #3530 from Ichoran/issue/6632Adriaan Moors2014-02-141-1/+4
|\ \ \ | | | | | | | | SI-6632 ListBuffer's updated accepts negative positions
| * | | SI-6632 ListBuffer's updated accepts negative positionsRex Kerr2014-02-131-1/+4
| |/ / | | | | | | | | | | | | | | | 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.
* / / SI-8153 Mutation is hard, let's go shopping with an empty listRex Kerr2014-02-121-14/+13
|/ / | | | | | | | | | | | | | | | | | | 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).
* | Merge pull request #3437 from Ichoran/issue/6736Adriaan Moors2014-02-121-31/+116
|\ \ | | | | | | SI-6736 Range.contains is wrong
| * | Reasonable Range operations consistently work when overfull.Rex Kerr2014-02-091-24/+105
| | | | | | | | | | | | | | | | | | 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.
| * | SI-6736 Range.contains is wrongRex Kerr2014-02-091-7/+11
| | | | | | | | | | | | Removed once-used private method that was calculating ranges in error and corrected the contains method (plus improved performance).
* | | Merge pull request #3454 from Ichoran/issue/5994Grzegorz Kossakowski2014-02-112-14/+36
|\ \ \ | |_|/ |/| | SI-5994 battling implicits for String.lines
| * | SI-5994 battling implicits for String.linesRex Kerr2014-02-102-14/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | SI-8167 readLine shold flush output before reading inputJason Zaugg2014-02-111-1/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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".
* | Merge pull request #3480 from paulp/pr/publicize-abstract-starGrzegorz Kossakowski2014-02-1012-14/+14
|\ \ | | | | | | Make the Abstract* classes public.
| * | SI-6948 Make the Abstract* classes public.Paul Phillips2014-02-0612-14/+14
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #3470 from demobox/si-8215-follow-upAdriaan Moors2014-02-091-3/+4
|\ \ | | | | | | SI-8215: Correcting typo and splitting a long sentence in MatchIterator doc
| * | SI-8215: Correcting typo and splitting a long sentence in MatchIterator docAndrew Phillips2014-02-051-3/+4
| |/ | | | | | | Follow-up to 9c0ca62
* / SI-8154 AnyRefMap iterates its way to ((null, null))Rex Kerr2014-02-091-15/+12
|/ | | | | | Changed logic to prevent mutation between hasNext and next from delivering invalid results. Also fixed superscripts in scaladoc.
* Merge pull request #3432 from havocp/patch-1Adriaan Moors2014-02-051-2/+38
|\ | | | | Improve ExecutionContext implicitNotFound and docs
| * Improve ExecutionContext implicitNotFound and docsHavoc Pennington2014-01-311-2/+38
| | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #3453 from Ichoran/issue/4997Adriaan Moors2014-02-051-0/+1
|\ \ | | | | | | SI-4997 deprecate StringLike.linesIterator for StringLike.lines
| * | SI-4997 deprecate StringLike.linesIterator for StringLike.linesRex Kerr2014-01-311-0/+1
| | | | | | | | | | | | Deprecated. lines is by far more consistent with the rest of the naming in the library.
* | | PR #3233 cleanupPavel Pavlov2014-02-051-32/+31
| | | | | | | | | | | | | | | - `::.head` became a `val`; excessive accessor removed - SerializationProxy moved to `object List`
* | | Merge pull request #3439 from demobox/issue-8215Adriaan Moors2014-02-031-11/+28
|\ \ \ | | | | | | | | SI-8215: Document IllegalStateExceptions thrown by uninitialized MatchIterator from Regex (review by @heathermiller)
| * | | SI-8215 Documenting the possibility of IllegalStateExceptions when using ↵Andrew Phillips2014-02-011-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | MatchIterator See https://groups.google.com/forum/#!topic/scala-language/2T2wKVQiyVg
| * | | SI-8215 Removing ASCII art class diagram in Scaladoc for RegexAndrew Phillips2014-02-011-9/+1
| |/ / | | | | | | | | | | | | The Content Hierarchy contains the same information, properly formatted. See https://groups.google.com/d/msg/scala-language/2T2wKVQiyVg/3-iu19XSTxwJ
* | | Merge pull request #3445 from retronym/topic/opt7Grzegorz Kossakowski2014-02-021-0/+46
|\ \ \ | | | | | | | | Grab bag of compiler optimizations
| * | | More overrides for SetNJason Zaugg2014-02-011-0/+46
| |/ /
* / / SI-7266 Stream leaks memoryRex Kerr2014-01-311-2/+6
|/ / | | | | | | | | | | 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.)
* / SI-8213 AnyRefMap.getOrElseUpdate is faultyRex Kerr2014-01-302-4/+26
|/ | | | | | 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.
* Fix misuse of underscores.Paul Phillips2014-01-251-4/+4
| | | | | | 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].
* Merge pull request #3388 from rklaehn/issue/7445Adriaan Moors2014-01-242-17/+19
|\ | | | | ListMap.tail is returning wrong result
| * SI-7445 ListMap.tail is returning wrong resultRuediger Klaehn2014-01-202-17/+19
| | | | | | | | | | | | | | Reverted the commit that introduced the bug, and modified HashMap to no longer assume that tail is O(1). Review by @Ichoran, @soc
* | Improve naming of ReadStdinSimon Ochsenreither2014-01-183-32/+32
|/ | | | | We don't need to say everything twice, methods are already prefixed with “read”.
* Merge pull request #3322 from rklaehn/issue/6253Ichoran2014-01-161-14/+511
|\ | | | | SI-6253 HashSet should implement union
| * SI-6253 HashSet should implement unionRüdiger Klaehn2014-01-161-14/+511
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | SI-4370 Range bug: Wrong result for Long.MinValue to Long.MaxValue by ↵Rex Kerr2014-01-151-20/+71
|/ | | | | | | | | | | | | | 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.
* Merge pull request #3318 from rklaehn/issue/6196Ichoran2014-01-152-0/+243
|\ | | | | SI-6196 - Set should implement filter
| * SI-6200 - HashMap should implement filterRüdiger Klaehn2014-01-151-0/+122
| | | | | | | | | | | | | | | | | | 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.
| * SI-6196 - Set should implement filterRüdiger Klaehn2014-01-151-0/+121
| | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge pull request #3362 from som-snytt/issue/7544-scaladocAdriaan Moors2014-01-151-3/+2
|\ \ | | | | | | SI-7544 StringContext.f docs update
| * | SI-7544 StringContext.f docs updateSom Snytt2014-01-131-3/+2
| | | | | | | | | | | | | | | Correct the scaladoc to reflect how f"%" is handled, namely, it's no longer taken as f"%%".
* | | Merge pull request #3366 from Ichoran/issue/6457Adriaan Moors2014-01-154-6/+8
|\ \ \ | | | | | | | | SI-6457 ImmutableSetFactory.empty results in StackOverflowError
| * | | SI-6457 ImmutableSetFactory.empty results in StackOverflowErrorRex Kerr2014-01-144-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge pull request #3316 from Ichoran/topic/big-decimal-correctnessAdriaan Moors2014-01-152-71/+410
|\ \ \ \ | | | | | | | | | | Quasi-comprehensive BigDecimal soundness/correctness fix.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-30 01:35:11 +0000