| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|\
| |
| | |
SD-129 Mark JFunctionN as serializable
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
Improve performance and behavior of ListMap and ListSet
|
| | | |
|
| | |
| | |
| | |
| | | |
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.
|
| |/
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| | |
An empty string yields an empty iterator.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
use Future#foreach instead of onSuccess in example code
|
| | |
| | |
| | |
| | |
| | | |
bacause Future#onSuccess is deprecated
https://github.com/scala/scala/commit/fa0743c32338f147eaf7a
|
|\ \ \
| | | |
| | | | |
Avoid function chaining with reverse method
|
| | |/
| |/| |
|
|/ /
| |
| |
| |
| |
| | |
- 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.
|
| |
| |
| |
| |
| |
| | |
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._.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implicit conversions are now in package convert as ImplicitConversions,
ImplicitConversionsToScala and ImplicitConversionsToJava.
Deprecated WrapAsJava, WrapAsScala and the values in package object.
Improve documentation.
|
|\ \
| | |
| | | |
Remove the duplicate implem of hash codes for numbers.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | | |
The package list is on the right.
|
|\ \ \
| |/ /
|/| | |
SI-6710 / PR 5072 follow-up: fix Unit.box / Unit.unbox
|
| |/
| |
| |
| |
| |
| |
| | |
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`.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Because it was its only call site.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Because that is the only call site of that method.
|
| |
| |
| |
| | |
Because it is otherwise unused.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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.
|
|\
| |
| | |
Accomodate and exploit new library, lang features JDK 8
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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/
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
... 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.
|
| |
| |
| |
| | |
The API for doing so efficiently was made regular in Java 1.8.
|
| |
| |
| |
| |
| | |
By using newly introduced static methods in the Java standard
library.
|
|\ \
| | |
| | | |
Fix typo in the docs for the ++ method of Stream
|
| | | |
|
|\ \ \
| | | |
| | | | |
Add initial unit test for Catch and augment documentation
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
- Add unit test for andFinally
- Reduce code duplication in andFinally
- Extend documentation
|
|\ \ \
| |/ /
|/| | |
Unify treatment of built-in functions and SAMs
|