summaryrefslogtreecommitdiff
path: root/src/library
Commit message (Collapse)AuthorAgeFilesLines
* [squash] Fix bounds in containsSimon Ochsenreither2016-07-071-1/+1
|
* Right-bias EitherSimon Ochsenreither2016-05-271-76/+236
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add operations like map, flatMap which assume right-bias - Deprecate {Left,Right}Projection - Deprecate left and right in favor of swap - Add contains, toOption, toTry, toSeq and filterOrElse - toSeq returns collection.immutable.Seq instead of collection.Seq - Don't add get There are no incompatible changes. The only possibility of breakage that exists is when people have added extension methods named map, flatMap etc. to Either in the past doing something different than the methods added to Either now. One detail that moved the scales in favor of deprecating LeftProjection and RightProjection was the desire to have toSeq return scala.collection.immutable.Seq instead of scala.collection.Seq like LeftProjection and RightProjection do. Therefore keeping LeftProjection and RightProjection would introduce inconsistency. filter is called filterOrElse because filtering in a for-comprehension doesn't work if the method needs an explicit argument. contains was added as safer alternative to if (either.isRight && either.right.get == $something) ... While adding filter with an implicit zero value is possible, it's dangerous as it would require that developers add a "naked" implicit value of type A to their scope and it would close the door to a future in which the Scala standard library ships with Monoid and filter could exist with an implicit Monoid parameter.
* Merge pull request #5130 from retronym/ticket/SD-129Jason Zaugg2016-05-1923-23/+23
|\ | | | | SD-129 Mark JFunctionN as serializable
| * SD-129 Mark JFunctionN as serializableJason Zaugg2016-04-2723-23/+23
| | | | | | | | | | | | | | | | | | | | | | | | Before this change, if these were used as the target type of a lambda in Java source code, the lambda would not be serializable. This is somewhat suprising when contrasted with the way that Scala lambdas work in Scala source. Since we copied these classes over from scala-java8-compat, that project has opted to add Serializable as a parent to solve this issue. This commit brings our copy of these interfaces into line with that change.
* | Merge pull request #5103 from ruippeixotog/improve-list-map-set-perfLukas Rytz2016-05-172-305/+194
|\ \ | | | | | | Improve performance and behavior of ListMap and ListSet
| * | Add SerialVersionUID to ListSetRui Gonçalves2016-05-171-0/+3
| | |
| * | Make ListMap and ListSet implementations similarRui Gonçalves2016-05-172-247/+156
| | | | | | | | | | | | ListSet and ListMap are two collections which share the exact same internal structure. This commit makes the two approaches as similar as possible by renaming and reordering internal methods, improving their Scaladoc and their code style. The Scaladoc of the classes and companion objects is also improved in order to alert users of the time complexity of the collections' operations.
| * | Improve performance and behavior of ListMap and ListSetRui Gonçalves2016-05-172-62/+39
| |/ | | | | | | | | | | | | | | Makes the immutable `ListMap` and `ListSet` collections more alike one another, both in their semantics and in their performance. In terms of semantics, makes the `ListSet` iterator return the elements in their insertion order, as `ListMap` already does. While, as mentioned in SI-8985, `ListMap` and `ListSet` doesn't seem to make any guarantees in terms of iteration order, I believe users expect `ListSet` and `ListMap` to behave in the same way, particularly when they are implemented in the exact same way. In terms of performance, `ListSet` has a custom builder that avoids creation in O(N^2) time. However, this significantly reduces its performance in the creation of small sets, as its requires the instantiation and usage of an auxilliary HashSet. As `ListMap` and `ListSet` are only suitable for small sizes do to their performance characteristics, the builder is removed, the default `SetBuilder` being used instead.
* | SI-9773 Fix doc for "".lines (#5161)som-snytt2016-05-171-7/+9
| | | | | | An empty string yields an empty iterator.
* | Correct off-by-one error in Product documentation (#5148)Janek Bogucki2016-05-111-1/+1
| |
* | SI-9666: Use inline group names in Regex (#4990)som-snytt2016-05-111-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Delegate `Match group name` to the underlying `matcher`. If that fails, try explicit group names as a fall back. No attempt is made to correlate inline and explicit names. In the following case, either name is accepted: ``` new Regex("a(?<Bar>b*)c", "Bee") ``` But if names are reversed, the error is undetected: ``` new Regex("a(?<Bee>b*)(?<Bar>c)", "Bar", "Bee") ``` Throw IllegalArg on bad group name to be consistent with Java.
* | BitSet{1,2} conversion (#5127)Ruslan Sennov2016-05-111-5/+7
| | | | | | | | | | | | In current implementation when we set high word (elems1) of BitSet2 to zero, the result is BitSet2 again. I believe it is leading to excessive memory usage and result should be BitSet1. Private helper method createSmall(a: Long, b: Long) introduced.
* | Merge pull request #5083 from xuwei-k/fix-Future-scaladocJason Zaugg2016-05-051-2/+2
|\ \ | | | | | | use Future#foreach instead of onSuccess in example code
| * | use Future#foreach instead of onSuccess in example codexuwei-k2016-04-141-2/+2
| | | | | | | | | | | | | | | bacause Future#onSuccess is deprecated https://github.com/scala/scala/commit/fa0743c32338f147eaf7a
* | | Merge pull request #5132 from acdenhartog/patch-1Jason Zaugg2016-05-051-3/+1
|\ \ \ | | | | | | | | Avoid function chaining with reverse method
| * | | Avoid function chaining with reverse methodArno den Hartog2016-04-271-3/+1
| | |/ | |/|
* / | Add examples to Exception object and group members (#5111)Janek Bogucki2016-05-021-25/+165
|/ / | | | | | | | | | | - Extend main comment with additional examples - Group methods from a user perspective - List exceptions special cased by shouldRethrow - Include overlooked withTry in opt, either notes.
* | Rename the (deprecated) implicit conversion methods in JavaConversionsLukas Rytz2016-04-222-2/+38
| | | | | | | | | | | | Provide higher-priority implicit conversion methods whose names don't clash with methods in JavaConverters. This allows implicit conversions to work when importing both JavaConverters._ and JavaConversions._.
* | Cleaned up Scaladoc for JavaConverters and non-deprecated friendsLukas Rytz2016-04-227-872/+261
| |
* | SI-9684 Deprecate JavaConversionsSom Snytt2016-04-2215-58/+984
| | | | | | | | | | | | | | | | | | Implicit conversions are now in package convert as ImplicitConversions, ImplicitConversionsToScala and ImplicitConversionsToJava. Deprecated WrapAsJava, WrapAsScala and the values in package object. Improve documentation.
* | Merge pull request #5110 from sjrd/remove-duplicate-implem-of-hashcodesLukas Rytz2016-04-224-79/+45
|\ \ | | | | | | Remove the duplicate implem of hash codes for numbers.
| * | Remove the duplicate implem of hash codes for numbers.Sébastien Doeraene2016-04-214-66/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, there were two separate implementations of hash code for boxed number classes: * One in Statics, used by the codegen of case class methods. * One in ScalaRunTime + BoxesRunTime, used by everything else. This commit removes the variant implemented in ScalaRunTime + BoxesRunTime, and always uses Statics instead. We use Statics because the one from ScalaRunTime causes an unnecessary module load. The entry point ScalaRunTime.hash() is kept, as deprecated, for bootstrapping reasons.
| * | Bring Statics.doubleHash in sync with BoxesRunTime.hashFromDouble.Sébastien Doeraene2016-04-211-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The two algorithms were different, and could result in different hash codes for some values, namely, valid long values that were not also valid int values. The other two functions `longHash` and `floatHash` are rewritten to keep a common style with `doubleHash`, but their algorithm does not change.
* | | scala-dev-113: Sync root package words to layout (#5107)Janek Bogucki2016-04-201-1/+1
| | | | | | | | | The package list is on the right.
* | | Merge pull request #5100 from lrytz/unitBoxLukas Rytz2016-04-201-2/+2
|\ \ \ | |/ / |/| | SI-6710 / PR 5072 follow-up: fix Unit.box / Unit.unbox
| * | SI-6710 / PR 5072 follow-up: fix Unit.box / Unit.unboxLukas Rytz2016-04-201-2/+2
| |/ | | | | | | | | | | | | The backend replaces .box / .unbox methods by corresponding invocations to BoxesRunTime, but not for Unit. This commit restores the body of `Unit.box` and `Unit.unbox`.
* | Remove the unused scala.runtime.Boxed trait.Sébastien Doeraene2016-04-131-12/+0
| |
* | Remove plain old dead code in ScalaRunTime.Sébastien Doeraene2016-04-131-26/+0
| |
* | Move ScalaRunTime.box to typechecker.Macros.Sébastien Doeraene2016-04-131-13/+0
| | | | | | | | Because it was its only call site.
* | Inline ScalaRunTime.arrayElementClass at call sites.Sébastien Doeraene2016-04-135-23/+10
| | | | | | | | | | | | | | | | | | | | This method was awful. Not only it was using run-time type tests to essentially encode compile-time overloading. But it also did 2 slightly different things for the Class case and ClassTag case. All in all, it is much more readable to inline the appropriate implementation at every call site.
* | Move ScalaRunTime.isAnyVal to reify.phases.Reify.Sébastien Doeraene2016-04-131-5/+0
| | | | | | | | Because that is the only call site of that method.
* | Hide ScalaRunTime.isTuple inside stringOf.Sébastien Doeraene2016-04-131-2/+3
| | | | | | | | Because it is otherwise unused.
* | Remove dead-code runtime hash() methods.Sébastien Doeraene2016-04-132-44/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | ScalaRunTime had a bunch of overloads of the `hash()` method, but only the `Any` version is ever used by the codegen. Worse, their implementation was not in sync with the actual implementations in BoxesRunTime, called by the `Any` version. For example, hash(0x80000000L) != hash(0x80000000L: Any) This commit simply removes all of this dead code. Similarly, we remove BoxesRunTime.hashFromObject(), which was never called either.
* | Inline ArrayRuntime methods in ScalaRunTime.array_clone().Sébastien Doeraene2016-04-132-35/+9
|/ | | | | | | | | | | | | | Support for Array[T].clone() was introduced in 36ef60e68c03bc1c7fd2e910ae7d70d4ec32d3bf. At the time, all calls to array.clone() were redirected to ScalaRunTime.array_clone(), which meant that array_clone() itself could not be implemented in terms of `x.clone()`. A Java binding was necessary. Now, the rewriting to `array_clone()` is only done for unbounded generic arrays. Since all the calls within `array_clone()` are monomorphic arrays, the rewriting is not applied, and the Java binding is unnecessary.
* Delete unnecessary blank linesh0hei2016-04-071-2/+0
|
* Generate AnyVal source stubs from sbtStefan Zeiger2016-04-069-18/+18
| | | | | | | | | | | | The sbt command `generateSources` now generates both the AnyVal sources and the tuple/function sources (previously done by `genprod`). Source generation is part of the sbt build, the `scala.tools.cmd.gen` package is removed from `scala-compiler`. This simplifies bootstrapping. Generated sources are still in the same location and checked into git. The shell scripts `tools/codegen` and `tools/codegen-anyvals` are also removed. The ant build and the build scripts do not call these. Regenerating sources is a manual step at the moment.
* General cleanups and less warnings during a Scala buildsoc2016-04-048-27/+7
|
* SI-6710 Clarify stub methods in primitive value classesLukas Rytz2016-04-019-27/+36
| | | | | | | | | - Replaces the implementations of box/unbox in AnyVal companions by `???`, the methods are only stubs, and the impls did not correspond to the actual behavior. The doc comment already points to the actual implementation in BoxesRunTime. - Replaces the body of `getClass` from `null` to `???` and clarifies in a comment why the overrides exist.
* Merge pull request #5068 from retronym/topic/jdk8ism2v2.12.0-M4Lukas Rytz2016-04-018-51/+20
|\ | | | | Accomodate and exploit new library, lang features JDK 8
| * Use System.lineSeparator, rather than sys.propsJason Zaugg2016-03-293-4/+3
| |
| * Use Java's highestOneBit, rather than our own versions.Jason Zaugg2016-03-291-21/+2
| | | | | | | | | | | | | | | | | | | | | | The original code came from 2008, (a4ace382), at which point we probably couldn't use JDK 1.5+ methods. I haven't changed `unsignedCompare` yet to use the standard library version, as it our version might have different performance characteristics. Background: http://www.drmaciver.com/2008/08/unsigned-comparison-in-javascala/
| * Note the availability of writableStackTrace in JDK 1.7+Jason Zaugg2016-03-291-0/+2
| |
| * SI-7474 Record extra errors in Throwable#suppressedExceptionsJason Zaugg2016-03-291-7/+4
| | | | | | | | | | | | | | ... in parallel collection operations. Followup to bcbe38d18, which did away with the the approach to use a composite exception when more than one error happened.
| * Delegate more primitive comparison to the Java stdlibJason Zaugg2016-03-291-16/+6
| | | | | | | | The API for doing so efficiently was made regular in Java 1.8.
| * Avoid intermediate boxing in BoxesRuntime.hashCodeFromJason Zaugg2016-03-291-3/+3
| | | | | | | | | | By using newly introduced static methods in the Java standard library.
* | Merge pull request #5070 from markus1189/stream-docsLukas Rytz2016-04-011-1/+1
|\ \ | | | | | | Fix typo in the docs for the ++ method of Stream
| * | Fix typo in the docs for the ++ method of StreamMarkus Hauck2016-03-311-1/+1
| | |
* | | Merge pull request #5071 from janekdb/topic/2.12.x-scaladoc-ExceptionsLukas Rytz2016-04-011-7/+13
|\ \ \ | | | | | | | | Add initial unit test for Catch and augment documentation
| * | | Add initial unit test for Catch and augment documentationJanek Bogucki2016-03-311-7/+13
| |/ / | | | | | | | | | | | | | | | - Add unit test for andFinally - Reduce code duplication in andFinally - Extend documentation
* | | Merge pull request #4971 from adriaanm/genbcode-delambdafyAdriaan Moors2016-03-311-1/+5
|\ \ \ | |/ / |/| | Unify treatment of built-in functions and SAMs