summaryrefslogtreecommitdiff
path: root/src/library
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #3563 from adriaanm/t5479Grzegorz Kossakowski2014-02-222-0/+6
|\ | | | | SI-5479 deprecate DelayedInit outside of App
| * SI-5479 link to release notes instead of jira queryAdriaan Moors2014-02-201-1/+1
| |
| * SI-5479 deprecate DelayedInit outside of AppAdriaan Moors2014-02-192-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | DelayedInit's semantics are way too surprising. For example, it delays initialization of fields, so that fields on objects that extend `App` (which `extends DelayedInit`) are not initialized until the `main` method is called. For more details and a proposed alternative, see https://issues.scala-lang.org/browse/SI-4330?jql=labels%20%3D%20delayedinit%20AND%20resolution%20%3D%20unresolved. Support for `App` will continue -- we'll special case it.
* | SI-7788 Avoid accidental shadowing of Predef.conformsAdriaan Moors2014-02-181-3/+7
| | | | | | | | | | | | | | Rename `conforms` to `$conforms` and put in a minimal backstop: pos/t7788.scala TODO: predicate the backwards compatibility shim for `Predef_conforms` on `-Xsource:2.10`
* | SI-8229 Source compatible name for implicit any2stringaddJason Zaugg2014-02-181-3/+10
|/ | | | | | | | | | To support the established pattern for disabling it for an compilation unit. Update scaladoc's knowledge of our "typeclasses". Leave a `private[scala]` version of `StringAdd` (public in bytecode) to ensure binary compatibility with 2.11.0-M8 for partest.
* SI-8072 rationalize public implicits in scala parallel collectionsRex Kerr2014-02-183-32/+43
| | | | | | | | Pretty much everything seems like it's intended for internal use, so I moved it to a package-private object. Split toParArray out and put it in an implicit class. Added ability to .toParArray from Array and String also. Added test to verify implicits are gone.
* 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-23 02:37:25 +0000