| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
The continuations plugin and library will still ship with 2.11 (albeit unsupported).
They now reside at https://github.com/scala/scala-continuations.
|
| |\
| |
| | |
SI-7618 Remove octal number literals
|
| | |
| |
| |
| |
| |
| | |
This also fixes a spurious detection of octal literals in floating
point literals: Literals like 01.23 are neither deprecated nor planned
for removal.
|
| |\ \
| | |
| | | |
SI-8059 Override immutable.Queue#{+:,:+} for performance
|
| | | |
| | |
| | |
| | | |
Without those overrides, all elements are unnecessarily copied.
|
| |\ \ \
| | | |
| | | | |
Merge 2.10.x to master
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
build.examples.xml
build.xml
docs/examples/actors/pingpong.scala
docs/examples/fors.scala
docs/examples/iterators.scala
docs/examples/jolib/Ref.scala
docs/examples/jolib/parallelOr.scala
docs/examples/monads/callccInterpreter.scala
docs/examples/monads/directInterpreter.scala
docs/examples/monads/errorInterpreter.scala
docs/examples/monads/simpleInterpreter.scala
docs/examples/monads/stateInterpreter.scala
docs/examples/parsing/ArithmeticParser.scala
docs/examples/patterns.scala
docs/examples/pilib/elasticBuffer.scala
docs/examples/pilib/handover.scala
docs/examples/pilib/piNat.scala
docs/examples/typeinf.scala
src/build/pack.xml
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Otherwise, objects with exception-throwing `toString` lead to a
cascading error far removed from the originally failed match.
|
| | |\| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
bincompat-forward.whitelist.conf
src/interactive/scala/tools/nsc/interactive/Global.scala
test/files/presentation/scope-completion-2.check
test/files/presentation/scope-completion-3.check
test/files/presentation/scope-completion-import.check
Conflicts in the scope completion tests handled with the help
of @skyluc in https://github.com/scala/scala/pull/3264
|
| | | |\ \ \
| | | | | |
| | | | | | |
SI-8029 Avoid multi-run cyclic error with companions, package object
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The bug report suggests this problem only became visible in the
IDE *after* 2.10.3, but I tested an IDE with exactly 2.10.3 and
saw the same problem.
In fact, my test case fails as far back as 2.10.0. I suspect the
problem showed up after 816cecf9a9, which checks that pairs of
companion symbols are codefined eagerly in Namers.
This commit modifies the check of `rawInfo ne NoType`
in `isCoDefinedWith` to avoid triggering adaptation of types from
the previous run. I'm not sure of the precise intent of that check.
I looked at c9861cd198 (genesis of isCoDefinedWith). Before that we
get back to 3761cb4b3a1 (the dawn of Subversion.)
|
| | | |\ \ \ \
| | | | | | |
| | | | | | | |
[backport] SI-7439 Avoid NPE in `isMonomorphicType` with stub symbols.
|
| | | | |/ / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`originalInfo` can return null for stub symbols; deal with that
as we used to before a regression in 016bc3db.
After this change, we can once again delete A_1.class and still compile
code instantiating B_1. (A_1 is only referred to in a method signature
of B_1 which is not called from our code.)
scala> new B_1
warning: Class A_1 not found - continuing with a stub.
res0: B_1 = B_1@5284b8f9
In practice, this situation arises when someone uses a third
party class that was compiled against other libraries not avaialable
on the current compilation classpath.
(cherry picked from commit a95432168204964e4f6c4571e781559c1640f2d8)
|
| | |\| | | |
| | |_|/ /
| |/| | |
| | | | |
| | | | | |
Conflicts:
src/compiler/scala/tools/nsc/transform/Erasure.scala
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Calls to `Symbol#info` during scope iteration considered harmful.
Looks like calling `info` during this Scope iteration is triggering
the ExplicitOuter info transformer, which "makes all super accessors
and modules in traits non-private, mangling their names.". This name
change necessitates a rehashing of the owning scope, which I suspect
is enough to corrupt the ScopeEntry-s being traversed in
`checkNoDeclaredDoubleDefs`.
The upshot was that we encountered the same symbol twice, which was
reported as being a double-definition.
This problem only showed up after 086702d8a74, which did nothing
worse then change the order in which `{e, e1}.sym.info` were
forced.
I inspected SymbolPairs/OverridingPairs which *appear* to be immune
as they only test flags during scope iteration; infos are not used
until later, at which point we're iterating a temporary scope that
isn't part of the type of the owner of the symbols.
|
| | | |\ \
| | | | |
| | | | | |
teaches toolbox about -Yrangepos
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Unlike in master, in 2.10.x enabling -Yrangepos requires instantiating
Global with mixed in RangePositions trait.
Same story for toolboxes. Just setting Yrangepos is not enough - one
needs to mix in RangePositions into ToolboxGlobal. I didn’t know that
back then, so now I’m fixing the oversight.
The commit is marked as [nomaster], because -Yrangepos doesn’t need
special treatment in master.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Plugins get a class path
|
| | | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Let -Xplugin specify a class path (or multiple of them).
Each entry can be a jar or dir, and the first entry to supply
a plugin descriptor defines the plugin to load.
If no plugin is found on the path, then issue a warning if `-Xdev`.
This honors the legacy silent treatment (which scala-ide tests for).
In the proposed scheme, each plugin gets a class loader so that
plugins are isolated from each other.
Presumably, if compiler plugins were a rich ecosystem, in which
shared dependencies were required in incompatible versions, this
would have become a requirement by now.
(Updated with a `DirectTest` that uses two plugins, but keeping
the following as documentation.)
Partest can't do multiple plugins yet, but this is what it looks like:
```
skalac -Xplugin:sample.jar:useful.jar:util,needful.jar:another.jar:util,needful.jar:util:exploded -Xplugin-require:sample,another,other foo.scala
skalac -Xplugin:sample.jar:useful.jar:util,needful.jar:another.jar:util,needful.jar:util:exploded -Xplugin-require:sample,other -Xplugin-disable:another foo.scala
skalac -Xplugin:sample.jar:useful.jar:util,sample.jar:useful.jar:util -Xplugin-require:sample foo.scala
```
The manual test shows three plugins with various permutations of jars and dirs.
The manual test demonstrates that plugins only see classes on their class path:
```
Initializing test.plugins.SamplePlugin
needful.Needful? Failure(java.lang.ClassNotFoundException: needful.Needful)
useful.Useful? Success(class useful.Useful)
Initializing more.plugins.AnotherPlugin
needful.Needful? Success(class needful.Needful)
useful.Useful? Failure(java.lang.ClassNotFoundException: useful.Useful)
Initializing other.plugins.OtherPlugin
```
Disabling a plugin results in a message instead of silent suppression:
```
Disabling plugin another
```
The duplicate plugin class test must still be honored:
```
Ignoring duplicate plugin sample (test.plugins.SamplePlugin)
Initializing test.plugins.SamplePlugin
needful.Needful? Failure(java.lang.ClassNotFoundException: needful.Needful)
useful.Useful? Success(class useful.Useful)
```
If the path is bad, then missing classes will report which plugin induced
the error:
```
Error: class not found: util/Probe required by test.plugins.SamplePlugin
Error: class not found: util/Probe required by more.plugins.AnotherPlugin
Initializing other.plugins.OtherPlugin
needful.Needful? Success(class needful.Needful)
useful.Useful? Failure(java.lang.ClassNotFoundException: useful.Useful)
error: Missing required plugin: sample
error: Missing required plugin: another
two errors found
```
|
| | |/ / /
|/| | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With the new focus on quasiquotes in macro implementations, we now have
to change the way how inference of macro def return types works.
Previously, if the return type of a macro def wasn’t specified, we looked into
the signature of its macro impl, took its return type (which could only
be c.Expr[T]) and then assigned T to be the return type of the macro def.
We also had a convenient special case which inferred Any in case when
the body of the macro impl wasn’t an expr. That avoided reporting spurious
errors if the macro impl had its body typed incorrectly (because in that
case we would report a def/impl signature mismatch anyway) and also provided
a convenience by letting macro impls end with `???`.
However now we also allow macro impls to return c.Tree, which means that
we are no longer able to do any meaningful type inference, because c.Tree
could correspond to tree of any type.
Unfortunately, when coupled with the type inference special case described
above, this means that the users who migrate from exprs to quasiquotes
are going to face an unpleasant surprise. If they haven’t provided
explicit return types for their macro defs, those types are going to be
silently inferred as `Any`!
This commit plugs this loophole by prohibiting type inference from
non-expr return types of macro impls (not counting Nothing). Moreover,
it also deprecates c.Expr[T] => T inference in order to avoid confusion
when switching between exprs and quasiquotes.
|
| |\ \ \
| | | |
| | | | |
Merge 2.10.x, and PR #3196, to master
|
| | |\| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
merge/2.10.x-positions-to-master
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Typers.scala
test/files/neg/applydynamic_sip.check
- Changes two calls from `.endOrPoint` to `.point`. The latter
is safe in master for both `Range`- and `OffsetPosition`s
- Updates checkfiles with unrelated position changes (constructors)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously there occurred a NoPosition error when one asks for position
information in the AST because no positions were set to the trees
created during the transformation for updateDynamic calls. This commit
applies range positions to the trees in order to being able to highlight
them inside of the scala-ide.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, there were no positions created for the tuples that are
generated while doing the transformation for an applyDynamicNamed call.
This led to an NoPosition error in scalac when one tries to show
position information in the AST. Furthermore, this simplifies semantic
highlighting in the scala-ide because no position information for color
ranges have to be created anymore.
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The new positions are range positions that directly refer to the
beginning and the end of the method calls in the sources instead of
simply point to the beginning of the expression. This allows the
scala-ide to semantically highlight select- and applyDynamic method
calls, because it has only to traverse the tree and apply the color
ranges to the given position ranges.
This also fixes the position marker of an error messages related
to a wrong Dynamic method signature.
|
| |\ \ \
| | | |
| | | | |
private access for local companions
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We go through similar gymnastics to make companion implicits
work for local class/object pairings, so we ought to be consistent
when it comes to access
|
| |\ \ \ \
| |_|/ /
|/| | | |
SI-4332 Plugs the gaps in views
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
These currently result in runtime errors:
scala> List(1).view.distinct.force
java.lang.UnsupportedOperationException: SeqView(...).newBuilder
scala> List(1).view.inits.toList
java.lang.UnsupportedOperationException: SeqView(...).newBuilder
Two tests are enclosed:
1. reflect on the views to make any method that returns
`Repr` is overriden in `*ViewLike`. This guards against
new additions to the collections API.
2. exercise the newly added overrides
Some care is needed with `tail`, we must re-override it
in `mutable.IndexedSeqView` to be explicit about the
end point of the slice, because the `IndexedSeqView#Sliced`
defines length in terms of that. (Higher up the chain, it
is just `iterator.size`, that's why `SeqView#tail` just sets
up a slice from `1 to Int.MaxValue`.)
Parallel collections views are not touched, as these are likely
to be deprecated or removed shortly.
Before this change, the test reported the following.
Not all of these methods were buggy. For instance, `sortBy`,
`sortWith` are implemented in terms of `sorted` which
was implemented in `SeqViewLike`. Even in those cases, I have
opted to override the methods in the `ViewLike` to guard
against changes in the base class implementation and to
simplify the rules in the test.
======================================================================
Checking scala.collection.TraversableView
======================================================================
trait TraversableLike
----------------------------------------------------------------------
def filterNot(p: A => Boolean): Repr
def inits: Iterator[Repr]
def tails: Iterator[Repr]
override def tail: Repr
======================================================================
Checking scala.collection.IterableView
======================================================================
trait IterableLike
----------------------------------------------------------------------
def dropRight(n: Int): Repr
def sliding(size: Int): Iterator[Repr]
def takeRight(n: Int): Repr
trait TraversableLike
----------------------------------------------------------------------
def filterNot(p: A => Boolean): Repr
def inits: Iterator[Repr]
def tails: Iterator[Repr]
override def tail: Repr
======================================================================
Checking scala.collection.SeqView
======================================================================
trait IterableLike
----------------------------------------------------------------------
def dropRight(n: Int): Repr
def sliding(size: Int): Iterator[Repr]
def takeRight(n: Int): Repr
trait SeqLike
----------------------------------------------------------------------
def combinations(n: Int): Iterator[Repr]
def distinct: Repr
def permutations: Iterator[Repr]
def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr
def sortWith(lt: (A, A) => Boolean): Repr
trait TraversableLike
----------------------------------------------------------------------
def filterNot(p: A => Boolean): Repr
def inits: Iterator[Repr]
def tails: Iterator[Repr]
override def tail: Repr
======================================================================
Checking scala.collection.mutable.IndexedSeqView
======================================================================
trait IndexedSeqOptimized
----------------------------------------------------------------------
override def dropRight(n: Int): Repr
override def tail: Repr
override def takeRight(n: Int): Repr
trait IterableLike
----------------------------------------------------------------------
def sliding(size: Int): Iterator[Repr]
trait SeqLike
----------------------------------------------------------------------
def combinations(n: Int): Iterator[Repr]
def distinct: Repr
def permutations: Iterator[Repr]
def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr
def sortWith(lt: (A, A) => Boolean): Repr
trait TraversableLike
----------------------------------------------------------------------
def filterNot(p: A => Boolean): Repr
def inits: Iterator[Repr]
def tails: Iterator[Repr]
======================================================================
Checking scala.collection.immutable.StreamView
======================================================================
trait IterableLike
----------------------------------------------------------------------
def dropRight(n: Int): Repr
def sliding(size: Int): Iterator[Repr]
def takeRight(n: Int): Repr
trait SeqLike
----------------------------------------------------------------------
def combinations(n: Int): Iterator[Repr]
def distinct: Repr
def permutations: Iterator[Repr]
def sortBy[B](f: A => B)(implicit ord: scala.math.Ordering[B]): Repr
def sortWith(lt: (A, A) => Boolean): Repr
trait TraversableLike
----------------------------------------------------------------------
def filterNot(p: A => Boolean): Repr
def inits: Iterator[Repr]
def tails: Iterator[Repr]
override def tail: Repr
|
| |\ \ \ \
| | | | |
| | | | | |
SI-8001 spurious "pure expression does nothing" warning
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`isPureExprForWarningPurposes` doesn’t warn on `()`, but `(): Unit`
leaves it confused. This patch fixes the problem.
The fix is important in the context of the recent split between blackbox
and whitebox macros. Macro engines wrap expansions of blackbox macros
in type ascriptions, so a macro that expands into `()` would actually
produce `(): Unit`, which would trigger a spurious warning. Thanks
@milessabin for spotting this problem!
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
Unifying -Ydelambdafy:{inline, method}
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Previously, new synthetic parameter symbols were created for the
apply method parameters, but only used in its `MethodType`. The
`ValDef` trees of the function, along with their symbols, were
used directly as the parameter trees of the apply method.
% cat sandbox/test.scala
object Test {
(x: Int) => {
(y: Int) => ???
}
}
% scalac-hash v2.10.3 -Xprint:typer,uncurry -uniqid ../scala2/sandbox/test.scala | egrep 'syntax|\bx'
[info] v2.10.3 => /Users/jason/usr/scala-v2.10.3-0-g88b5d19
[[syntax trees at end of typer]] // test.scala
((x#12152: Int#351) => x#12152)#12151
[[syntax trees at end of uncurry]] // test.scala
final def apply#15952(x#12152: Int#351): Int#351 = x#12152
This approach dates back a long way: c64152bc3. @odersky tells me it
was most likely due to insufficent substitution/cloning machinery
at the time.
% qbin/scalac -Xprint:typer,uncurry -uniqid ../scala2/sandbox/test.scala | egrep 'syntax|\bx'
[[syntax trees at end of typer]] // test.scala
((x#13685: Int#1760) => x#13685)#13671
[[syntax trees at end of uncurry]] // test.scala
final def apply#13959(x#13960: Int#1760): Int#1760 = x#13960
To make this work, I had to fix a problem in symbol substition; this
was commited in the previous commit. In the enclosed test, at Uncurry,
the symbol of the nested class `N` had a `ClassInfoType`, which listed
as a parent `M[a.C]`. When we substituted the new method parameter
symbol `a` for the eponymous function parameter symbol, this was not
touched.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
An upcoming change to uncurry, in which I plan to make substitution of
`lambda params -> apply method params` requires that I first to fix a
problem in symbol substition.
This situation can arise when the body of this definition:
def owner1(a: A) = {
class C extends M[a.B]
}
is transplanted into a new owner that has a different symbol for `a`.
I speculated that value classes might also be prone to the
fact that symbol substitution neglected `ClassInfoType#parents`.
We can test change with Value Classes: Partial Functions that are
dependent on value class param type used to fail with a spurious
overriding error, now they work correctly.
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
SI-7985 Allow qualified type argument in patterns
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As per the last commit, tighten up the interpretation of a lower
cased identifier meaning that we're looking at a type variable.
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We were considering the lower case `s` in `case _: Array[scala.Int]`
as a sign that we were dealing with a type variable pattern.
Now, we only do this if a lookahead confirms the absence of a the `.`
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Removing deprecated code.
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | | |
Code which has been deprecated since 2.10.0 and which allowed
for straightforward removal.
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | | |
Deprecate Pair and Triple
|
| | |/ / / |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Two kids in the class or '6329 had to repeat the senior year,
but with a little help from 76b92ef, they've finally graduated.
Here's the class photo:
commit 3e855661136bb6c530ef1d3a24dc83800e7f1134
Author: Eugene Burmako <xeno.by@gmail.com>
Date: Thu Sep 6 22:19:56 2012 +0200
test suite for SI-6329
test/files/run/t6329_repl.check | 13 +++++++++++++
test/files/run/t6329_repl.scala | 8 ++++++++
test/files/run/t6329_repl_bug.check | 13 +++++++++++++
test/files/run/t6329_repl_bug.pending | 10 ++++++++++
test/files/run/t6329_vanilla.check | 2 ++
test/files/run/t6329_vanilla.scala | 4 ++++
test/files/run/t6329_vanilla_bug.check | 2 ++
test/files/run/t6329_vanilla_bug.pending | 7 +++++++
8 files changed, 59 insertions(+)
|
| |\ \ \
| | | |
| | | | |
New mutable hash map with Long keys: partially solves SI-5263 and is relevant to SI-6825.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
An open addressing hash map based on a similar scheme to mutable.LongMap.
It delivers performance equivalent to Java's HashMap for pretty much all
AnyRefs, plus it works nicely with Scala's collections.
Revisions made sure that all return types in the public API are specified.
Also switched to a leading-zeros method of calculating the initial mask (to
save a few ns). Also edited out java.util comparison numbers and moved
constants to companion.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
to SI-6825.
The hash map is based on an open addressing scheme that provides
dramatically faster (mostly due to specialization) get and contains
operations than either the standard Java HashMap or any of the existing
Scala hash maps. It doesn't work well above 500,000,000 elements as
the arrays cannot scale past 2^30 elements. Maps are not faster in
general due to the lack of specialization of Function1[Long, V].
Revisions made sure that all return types in the public API are specified.
Also switched to a leading-zeros method of calculating the initial mask (to
save a few ns), and used an occasionally-more-efficient version of
seekEntryOrOpen. Also edited out specific performance numbers and moved
constants to companion.
|
| |\ \ \ \
| |_|/ /
|/| | | |
Revived tests that once depended on xml
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I was a bit overzealous in moving stuff over to scala-xml in 9c50dd5274
These were all compiler tests that accidentally touched on xml.
I've tried to delicately decouple them so they can roam the
scalac pastures as intended.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 04e2dbb29830d0e511cdfa8c132a9fad91d657ed,
by avoiding the ill-fated attempt to short-circuit the global
reflection lock.
I think we can do better performance wise, but lets at least
get something correct to start with.
|
| |\ \ \ \
| |/ / /
|/| | | |
Merge 2.10
|
