| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
| |
They were all annotated with `@deprecatedInheritance` in 2.11.0. Some
deprecated classes are moved to new source files in order to seal the
parent class. The package-private class `DoublingUnrolledBuffer` is
moved from `scala.collection.parallel.mutable` to
`scala.collection.mutable` in order to seal `UnrolledBuffer`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most immutable collections, including sets and maps, have a better-than-O(n) method for removing an element. In those cases, tail and possibly head were overridden so the head/tail pattern can be used with less of a performance penalty.
Speed improvements on head/tail pattern are
(for sets/maps of size 1024, unless otherwise specified):
```
BitSet 190x
HashSet 250x
Set 400x
Set2 9x
Set4 12x
HashMap 430x
ListMap 2500x // size 128
Map 430x
```
Note: `ListMap` is actually `init`/`last` because it's maintained in reverse order.
Altered ListMap docs to explain that reverse traversal is the fast way to do it.
All tested sets/maps that were already fast are still fast.
Test code is reproduced below, except it does ListSet with head/tail which
doesn't show the improvement:
```scala
object BenchTailSetMap {
val th = new ichi.bench.Thyme
val standard = 1 to 1024
val sets = Map[String, Set[Int]](
"Set" -> (Set.empty[Int] ++ standard),
"Set4"-> Set(4, 7, 2, 1),
"Set2"-> Set(3, 4),
"HashSet" -> (collection.immutable.HashSet.empty[Int] ++ standard),
"BitSet" -> (collection.immutable.BitSet.empty ++ standard),
"SortedSet" -> (collection.immutable.SortedSet.empty[Int] ++ standard),
"ListSet" -> (collection.immutable.ListSet.empty[Int] ++ standard)
)
val pairs = standard.map(i => i -> i.toString)
// ListMap implementation is HORRIBLE, O(n^3) tail! Cut down size.
val maps = Map[String, Map[Int, String]](
"Map" -> (Map.empty[Int, String] ++ pairs),
"HashMap" -> (collection.immutable.HashMap.empty[Int, String] ++ pairs),
"SortedMap" -> (collection.immutable.SortedMap.empty[Int, String] ++ pairs),
"ListMap" -> (collection.immutable.ListMap.empty[Int, String] ++ pairs.take(128))
)
def hts(s: Set[Int]) = {
var si = s
var x = 0
while (si.nonEmpty) {
x += si.head
si = si.tail
}
x
}
def htm(m: Map[Int, String]) = {
var mi = m
var x = 0
while (mi.nonEmpty) {
x += mi.head._2.length
mi = mi.tail
}
x
}
def run() {
sets.toList.sortBy(_._1).foreach{ case (name, s) => th.pbench(hts(s), s.size, name) }
maps.toList.sortBy(_._1).foreach{ case (name, m) => th.pbench(htm(m), m.size, name) }
}
}
```
|
| |
|
|
|
|
|
|
|
|
| |
- Language imports are preceding other imports
- Deleted empty file: InlineErasure
- Removed some unused private[parallel] methods in
scala/collection/parallel/package.scala
This removes hundreds of warnings when compiling with
"-Xlint -Ywarn-dead-code -Ywarn-unused -Ywarn-unused-import".
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
there were merge conflicts in the Eclipse config that I resolved with
--ours. I invite @performantdata to submit a followup PR bringing the
Eclipse stuff into a good state on 2.12.x.
there was a test failure in
test/junit/scala/collection/mutable/OpenHashMapTest.scala
due to the 2.12 compiler emitting the field backing a
private var differently (with an unmangled name). Lukas
says the difference is expected, so I just updated the
code in the test.
there were no other merge conflicts.
% git log --decorate --oneline -1 origin/2.11.x | cat
ae5f0de (origin/HEAD, origin/2.11.x) Merge pull request #4791 from performantdata/issue/9508
% git log --decorate --oneline -1 origin/2.12.x | cat
c99e53e (HEAD -> 2.12.x, origin/2.12.x) Merge pull request #4797 from lrytz/M3-versions
% export MB=$(git merge-base 2.12.x origin/2.11.x)
% echo $MB
42cafa21f3c4a08c6dd34608278f810b6ec2886f
% git log --graph --oneline --decorate $MB...origin/2.11.x | cat
* ae5f0de (origin/HEAD, origin/2.11.x) Merge pull request #4791 from performantdata/issue/9508
|\
| * 08dca37 (origin/pull/4791) SI-9508 fix classpaths in Eclipse configuration
* | fe76232 Merge pull request #4798 from performantdata/issue/9513
|\ \
| * | 9c97a7f (origin/pull/4798) Suppress unneeded import.
| * | 30d704d Document some OpenHashMap internal methods.
| * | 1fb32fc SI-9513 decrement "deleted" count in OpenHashMap.put() when slot reused
| |/
* | 14f875c Merge pull request #4788 from dk14/patch-1
|\ \
| * | 42acd55 (origin/pull/4788) explicitly specify insertion-order feature in docs
| /
* | 68ce049 Merge pull request #4771 from som-snytt/issue/9492-here
|\ \
| * | f290962 (origin/pull/4771) SI-9492 Line trimming paste
| * | bc3589d SI-9492 REPL paste here doc
| /
* | 9834fc8 Merge pull request #4610 from todesking/spec-implicits-remove-obsolete
|\ \
| * | 46009b1 (origin/pull/4610) Add view/context-bound parameter ordering rule
| * | 6eba305 Spec: Implicit parameters with context/view bound is allowed since 2.10
| /
* | d792e35 Merge pull request #4789 from janekdb/2.11.x-param-names-predicates-operations
|\ \
| |/
|/|
| * b19a07e (origin/pull/4789) Rename forall, exists and find predicate and operator params.
|/
* 648c7a1 Merge pull request #4790 from SethTisue/issue/9501
|\
| * 40d12f1 (origin/pull/4790) SI-9501 link README to Scala Hacker Guide
* e0b5891 Merge pull request #4786 from performantdata/issue/9506
* 39acad8 (origin/pull/4786) SI-9506 suppress Scala IDE-generated files in the Eclipse project dirs
* 74dc364 SI-9506 suppress Scala IDE-generated files in the Eclipse project dirs
% git merge ae5f0de
Auto-merging src/repl/scala/tools/nsc/interpreter/ILoop.scala
Auto-merging src/library/scala/util/Either.scala
Auto-merging src/library/scala/runtime/Tuple3Zipped.scala
Auto-merging src/library/scala/runtime/Tuple2Zipped.scala
Auto-merging src/library/scala/collection/parallel/ParIterableLike.scala
Auto-merging src/library/scala/collection/immutable/ListMap.scala
Auto-merging src/library/scala/collection/TraversableLike.scala
Auto-merging src/eclipse/test-junit/.classpath
CONFLICT (content): Merge conflict in src/eclipse/test-junit/.classpath
Auto-merging src/eclipse/scaladoc/.classpath
CONFLICT (content): Merge conflict in src/eclipse/scaladoc/.classpath
Auto-merging src/eclipse/scala-compiler/.classpath
Auto-merging src/eclipse/repl/.classpath
CONFLICT (content): Merge conflict in src/eclipse/repl/.classpath
Auto-merging src/eclipse/partest/.classpath
CONFLICT (content): Merge conflict in src/eclipse/partest/.classpath
Auto-merging src/eclipse/interactive/.classpath
Auto-merging README.md
Automatic merge failed; fix conflicts and then commit the result.
% git checkout --ours src/eclipse/partest/.classpath
% git checkout --ours src/eclipse/repl/.classpath
% git checkout --ours src/eclipse/scaladoc/.classpath
% git checkout --ours src/eclipse/test-junit/.classpath
% git add -u
% emacs test/junit/scala/collection/mutable/OpenHashMapTest.scala
% git diff test/junit/scala/collection/mutable/OpenHashMapTest.scala | cat
...
- val field = m.getClass.getDeclaredField("scala$collection$mutable$OpenHashMap$$deleted")
+ val field = m.getClass.getDeclaredField("deleted")
...
% git add -u
|
| | | |
|
| |/
|
|
|
|
| |
Added customized apply and contains methods for EmptyMap, Map1 - Map4 and ListMap (both EmptyListMap and Node).
The modifications appear to be able to (sometimes) change the SerialVersionUID of EmptyListMap, so that has been fixed at the old value.
|
| |
|
|
|
|
|
| |
Reverted the commit that introduced the bug, and modified HashMap to no
longer assume that tail is O(1).
Review by @Ichoran, @soc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collections library tidying, part one: scripting.
Everything in scala.collection.scripting is deprecated now, along with the
<< method that is implemented in a few other classes. Scripting does not
seem used at all, and anyone who did can easily write a wrapper that does
the same thing.
Deprecated *Proxy collections.
The only place proxies were used in the library was in swing.ListView, and
that was easy to change to a lazy val.
Proxy itself is used in ScalaNumberProxy and such, so it was left
undeprecated.
Deprecated Synchronized* traits from collections.
Synchronizability does not compose well, and it requires careful examination
of every method (which has not actually been done).
Places where the Scala codebase needs to be fixed (eventually) include:
scala.reflect.internal.util.Statistics$QuantMap
scala.tools.nsc.interactive.Global (several places)
Deprecated LinkedList (including Double- and -Like variants).
Interface is idiosyncratic and dangerously low-level. Although some
low-level functionality of this sort would be useful, this doesn't seem
to be the ideal implementation.
Also deprecated the extractFirst method in Queue as it exposes LinkedList.
Cannot shift internal representations away from LinkedList at this time
because of that method.
Deprecated non-finality of several toX collection methods.
Improved documentation of most toX collection methods to describe what the
expectation is for their behavior. Additionally deprecated overriding of
- toIterator in IterableLike (should always forward to iterator)
- toTraversable in TraversableLike (should always return self)
- toIndexedSeq in immutable.IndexedSeq (should always return self)
- toMap in immutable.Map (should always return self)
- toSet in immutable.Set (should always return self)
Did not do anything with IterableLike.toIterable or Seq/SeqLike.toSeq since
for some odd reason immutable.Range overrides those.
Deprecated Forwarders from collections.
Forwarding, without an automatic mechanism to keep up to date with changes
in the forwarded class, is inherently unreliable. Absent a mechanism to
keep current, they're deprecated. ListBuffer is the only class in the
collections library that uses forwarders, and that functionality can be
rolled into ListBuffer itself.
Deprecating immutable set/map adaptors.
They're a bad idea (barring compiler support) for the same reason that all
the other adaptors are a bad idea: they get out of date and probably have a
variety of performance bugs.
Deprecated inheritance from leaf classes in immutable collections.
Inheriting from leaf-classes in immutable collections is rarely a good idea
since whenever you use any interesting collections method you'll revert to
the original class. Also, the methods are often designed to work with only
particular behavior, and an override would be difficult (at best) to make
work. Fortunately, people seem to have realized this and there are few to
no cases of people extending PagedSeq and TreeSet and the like.
Note that in many cases the classes will become sealed not final.
Deprecated overriding of methods and inheritance from various mutable
collections.
Some mutable collections seem unsuited for overriding since to override
anything interesting you would need vast knowledge of internal data
structures and/or access to private methods. These include
- ArrayBuilder.ofX classes.
- ArrayOps
- Some methods of BitSet (moved others from private to protected final)
- Some methods of HashTable and FlatHashTable
- Some methods of HashMap and HashSet (esp += and -= which just forward)
- Some methods of other maps and sets (LinkedHashX, ListMap, TreeSet)
- PriorityQueue
- UnrolledBuffer
This is a somewhat aggressive deprecation, the theory being better to try it
out now and back off if it's too much than not attempt the change and be
stuck with collections that can neither be safely inherited nor have
implementation details changed.
Note that I have made no changes--in this commit--which would cause
deprecation warnings in any of the Scala projects available on Maven (at
least as gathered by Adriaan). There are deprecation warnings induced
within the library (esp. for classes/traits that should become static) and
the compiler. I have not attempted to fix all the deprecations in the
compiler as some of them touch the IDE API (but these mostly involved
Synchronized which is inherently unsafe, so this should be fixed
eventually in coordination with the IDE code base(s)).
Updated test checks to include new deprecations.
Used a higher level implementation for messages in JavapClass.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One last flurry with the broom before I leave you slobs to code
in your own filth. Eliminated all the trailing whitespace I
could manage, with special prejudice reserved for the test cases
which depended on the preservation of trailing whitespace.
Was reminded I cannot figure out how to eliminate the trailing
space on the "scala> " prompt in repl transcripts. At least
reduced the number of such empty prompts by trimming transcript
code on the way in.
Routed ConsoleReporter's "printMessage" through a trailing
whitespace stripping method which might help futureproof
against the future of whitespace diseases. Deleted the up-to-40
lines of trailing whitespace found in various library files.
It seems like only yesterday we performed whitespace surgery
on the whole repo. Clearly it doesn't stick very well. I suggest
it would work better to enforce a few requirements on the way in.
|
| |
|
|
|
|
|
| |
Current imperative version constructs a new ListMap regardless of
the fact the map doesn't contain the element. Replace it with the
tail-recursive variant that conserves. Also replace some usages with
the invariant now held.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Confusing, now-it-happens now-it-doesn't mysteries lurk
in the darkness. When scala packages are declared like this:
package scala.collection.mutable
Then paths relative to scala can easily be broken via the unlucky
presence of an empty (or nonempty) directory. Example:
// a.scala
package scala.foo
class Bar { new util.Random }
% scalac ./a.scala
% mkdir util
% scalac ./a.scala
./a.scala:4: error: type Random is not a member of package util
new util.Random
^
one error found
There are two ways to play defense against this:
- don't use relative paths; okay sometimes, less so others
- don't "opt out" of the scala package
This commit mostly pursues the latter, with occasional doses
of the former.
I created a scratch directory containing these empty directories:
actors annotation ant api asm beans cmd collection compat
concurrent control convert docutil dtd duration event factory
forkjoin generic hashing immutable impl include internal io
logging macros man1 matching math meta model mutable nsc parallel
parsing partest persistent process pull ref reflect reify remote
runtime scalap scheduler script swing sys text threadpool tools
transform unchecked util xml
I stopped when I could compile the main src directories
even with all those empties on my classpath.
|
| |
|
|
|
|
|
|
|
|
| |
a key is not found
Current implementation of apply0 relies on tail method to iterate over all keys.
When the list gets to its end, tail produces an 'empty map' message in its exception, which is thrown by ListMap.
This change checks if the collection is empty before calling tail and provides a more appropriate key not found message.
Signed-off-by: Vinicius Miana <vinicius@miana.com.br>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These things are killing me. Constructions like
package scala.foo.bar.baz
import foo.Other
DO NOT WORK in general. Such files are not really in the
"scala" package, because it is not declared
package scala
package foo.bar.baz
And there is a second problem: using a relative path name means
compilation will fail in the presence of a directory of the same
name, e.g.
% mkdir reflect
% scalac src/reflect/scala/reflect/internal/util/Position.scala
src/reflect/scala/reflect/internal/util/Position.scala:9: error:
object ClassTag is not a member of package reflect
import reflect.ClassTag
^
src/reflect/scala/reflect/internal/util/Position.scala:10: error:
object base is not a member of package reflect
import reflect.base.Attachments
^
As a rule, do not use relative package paths unless you have
explicitly imported the path to which you think you are relative.
Better yet, don't use them at all. Unfortunately they mostly work
because scala variously thinks everything scala.* is in the scala
package and/or because you usually aren't bootstrapping and it
falls through to an existing version of the class already on the
classpath.
Making the paths explicit is not a complete solution -
in particular, we remain enormously vulnerable to any directory
or package called "scala" which isn't ours - but it greatly
limts the severity of the problem.
|
| |
|
|
| |
That way it is possible to check if a ListMap has one element by checking x.tail.isEmpty. Size is O(1), so size==1 won't do!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Match @param/@tparam names to the actual parameter name
- Use @tparam for type parameters
- Whitespace is required between `*` and `@`
- Fix incorrect references to @define macros.
- Use of monospace `` and {{{}}} (much more needed)
- Remove `@param p1 ...` stubs, which appear in the generated docss.
- But, retainsed `@param p1` stubs, assuming they will be filtered from
the generated docs by SI-5795.
- Avoid use of the shorthand `@param doc for the solitary param`
(which works, but isn't recognized by the code inspection in IntelliJ
I used to sweep through the problems)
The remaining warnings from `ant docs` seem spurious, I suspect they are
an unintended consequence of documenting extension methods.
[scaladoc] /Users/jason/code/scala/src/library/scala/collection/TraversableOnce.scala:181: warning: Variable coll undefined in comment for method reduceOption in class Tuple2Zipped
[scaladoc] def reduceOption[A1 >: A](op: (A1, A1) => A1): Option[A1] = reduceLeftOption(op)
[scaladoc] ^
|
| | |
|
| |
|
|
|
|
| |
Change scaladoc links in collection classes to point at re-formatted
Collections Overview on docs.scala-lang.org. Fix minor typo:
s/Ummutable/Immutable
|
| |
|
|
| |
"The Scala 2.8 Collections API" overview.
|
| |
|
|
|
|
|
| |
Misc cleanups associated with the previous commits: limiting overly
expanded types, fixing externally visible types for scaladoc, utilizing
abstract collection classes where possible, etc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit and the two subsequent commits were contributed by:
Todd Vierling <tv@duh.org>.
I combined some commits and mangled his commit messages, but all the
credit is his. This pursues the same approach to classfile reduction
seen in r19989 when AbstractFunctionN was introduced, but applies it to
the collections. Thanks to -Xlint it's easy to verify that the private
types don't escape.
Design considerations as articulated by Todd:
* Don't necessarily create concrete types for _everything_. Where a
subtrait only provides a few additional methods, don't bother; instead,
use the supertrait's concrete class and retain the "with". For example,
"extends AbstractSeq[A] with LinearSeq[A]".
* Examine all classes with .class file size greater than 10k. Named
classes and class names ending in $$anon$<num> are candidates for
analysis.
* If a return type is currently inferred where an anon subclass would be
returned, make the return type explicit. Don't allow the library-private
abstract classes to leak into the public namespace [and scaladoc].
|
| |
|
|
|
|
|
| |
Iterators should have def next(), not def next. Clearing
a mutable structure should be done with clear(), not clear.
And etc. No review.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactoring the collections api to support differentiation between
referring to a sequential collection and a parallel collection, and to
support referring to both types of collections.
New set of traits Gen* are now superclasses of both their * and Par* subclasses. For example, GenIterable is a superclass of both Iterable and ParIterable. Iterable and ParIterable are not in a subclassing relation. The new class hierarchy is illustrated below (simplified, not all relations and classes are shown):
TraversableOnce --> GenTraversableOnce
^ ^
| |
Traversable --> GenTraversable
^ ^
| |
Iterable --> GenIterable <-- ParIterable
^ ^ ^
| | |
Seq --> GenSeq <-- ParSeq
(the *Like, *View and *ViewLike traits have a similar hierarchy)
General views extract common view functionality from parallel and
sequential collections.
This design also allows for more flexible extensions to the collections
framework. It also allows slowly factoring out common functionality up
into Gen* traits.
From now on, it is possible to write this:
import collection._
val p = parallel.ParSeq(1, 2, 3)
val g: GenSeq[Int] = p // meaning a General Sequence
val s = g.seq // type of s is Seq[Int]
for (elem <- g) {
// do something without guarantees on sequentiality of foreach
// this foreach may be executed in parallel
}
for (elem <- s) {
// do something with a guarantee that foreach is executed in order, sequentially
}
for (elem <- p) {
// do something concurrently, in parallel
}
This also means that some signatures had to be changed. For example,
method `flatMap` now takes `A => GenTraversableOnce[B]`, and `zip` takes
a `GenIterable[B]`.
Also, there are mutable & immutable Gen* trait variants. They have
generic companion functionality.
|
| |
|
|
|
|
|
|
| |
Revert "Added missing string prefixes for names of map and set
collection classes." and related commits.
No review.
|
| |
|
|
|
|
| |
Added missing string prefixes for names of map and set collection
classes.
|
| | |
|
| |
|
|
|
|
|
|
| |
Modified generic companion apply to call empty if there are no
arguments, so something like Set() does not generate unnecessary
garbage. Also found some immutable classes which don't reuse an empty
object for emptiness, and gave them one. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deprecated the @serializable annotation, introduce a new trait
"scala.Serializable" which has to be extended instead (cross-platform).
Known issues:
- Companion objects of serializable classes (including case classes) are automatically made serializable. However, they don't extend "Serializable" statically because of the known difficulty (should be done before typing, but hard).
- Writing "case class C() extends Serializable" gives "error: trait Serializable is inherited twice"
- Functions are serializable, but don't extend Serializable dynamically (could be fixed by making FunctionN Serializable - shouldn't we?)
Note that @SerialVersionUID continues to be an annotation; it generates
a static field, which is not possible otherwise in scala.
Review by dragos, extempore.
Question to dragos: in JavaPlatform.isMaybeBoxed, why is there a test
for "JavaSerializableClass"? Is that correct?
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
| |
Another fix for #3989, regarding the `-` which also used to cause stack
overflows. No review.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
| |
Fixes #3989, adding test cases for #3989 and #3996.
No review.
|
| | |
|
| |
|
|
|
|
|
| |
Discovered ListMap.++ returns a Map instead of a ListMap. Does
preserving binary compatibility mean we can't fix this sort of thing?
Fixing for now, inquiring via: review by odersky.
|
| |
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Changes to docs of collections in the `immutable` package. Review by
odersky.
|
| |
|
|
|
|
|
|
|
| |
As a brief diversion from real work, implemented Damerau–Levenshtein
and ran it on trunk to elicit obvious misspellings. Unfortunately
they're mostly in places like compiler comments which real people never
see, but I fixed them anyway. All those English Lit majors who peruse
our sources are sure to be pleased. No review.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
renamed BuilderFactory[El, To, From] -> CanBuildFrom[From, El, To] and
added apply() overload to create collections from scratch generically
added def apply() overload to BuilderFactory so that we can also create collections from scratch generically
(see test test/files/pos/collectGenericCC.scala)
renaming:
- BuilderFactory[El, To, From] -> CanBuildFrom[From, El, To]
bulk type-param reordering using: s/CanBuildFrom\[\s*([^,()\s]*)\s*,(\s+[^\s,()]*)\s*,\s+([^\s,()]*)\s*\]/CanBuildFrom[$3, $1,$2]/
some argument lists got mixed up because they contained 4 comma's...
- builderFactory -> canBuildFrom
removed explicit implicit value in DocDriver that was
renamed renamed collection/generic/BuilderFactory.scala ->
collection/generic/CanBuildFrom.scala
tested with clean build using ant strap.done -- everything went well on my machine
|
| | |
|
| | |
|
| |
|
|
|
|
| |
fixed headers/comments/svn props, made some progress with serializable
classes
|
| | |
|
| |
|
|
|
|
| |
In "Iterable" and in all its subclasses, "iterator" replaces "elements"
(and assorted changes).
|
