| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'U' is the common choice for the foreach function result tparam.
This command summarises the naming diversity before and after this change.
$ fgrep -r 'def foreach[' *|cut -f2 -d:|cut -f1 -d'('|tr -s ' '|sed 's/override //g'|sort|uniq -c|sort -nr
Before,
80 def foreach[U]
6 def foreach[C]
6 def foreach[B]
4 final def foreach[U]
3 def foreach[S]
2 inline final def foreach[U]
2 def foreach[A]
1 inline final def foreach[specialized
1 final def foreach[B]
1 * def foreach[U]
1 def foreach[Q]
1 def foreach[D]
1 def foreach[A,B,U]
After,
98 def foreach[U]
5 final def foreach[U]
2 inline final def foreach[U]
1 inline final def foreach[specialized
1 * def foreach[U]
1 def foreach[A,B,U]
(@ symbols removed.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'ac432bcde6':
Fix broken build.
SI-6434 Pretty print function types with by name arg as (=> A) => B
Removed class files.
SI-6994 Avoid spurious promiscuous catch warning
Addressing warnings.
SI-6439 Avoid spurious REPL warnings about companionship
use ArrayBuffer instead of Array to build Formulae
SI-6942 more efficient unreachability analysis
use Constant::isIntRange even if it's NIH
SI-6956 determine switchability by type, not tree
SI-5568 Comment improvements for getClass on primitive intersection.
SI-5568 Fixes verify error from getClass on refinement of value type
SI-6923 Context now buffers warnings as well as errors
Conflicts:
src/compiler/scala/tools/nsc/interpreter/IMain.scala
src/compiler/scala/tools/nsc/transform/Erasure.scala
src/compiler/scala/tools/nsc/typechecker/Contexts.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
test/files/neg/t4851.check
Note:
This merge excludes b07228aebe7a as it breaks master.
|
| | |
| |
| |
| |
| |
| |
| | |
- SI-6923 uncovered a few valid warnings, these have been
addressed.
- A pair of "catches all throwable" warnings appeared; one
of the is spurious and the subject of SI-6994.
|
| | |
| |
| |
| |
| |
| | |
Makes FlatHashTable#remove return a boolean instead of Option[A].
Updates HashSet accordingly. Adds a test to make sure remove
works as advertised.
|
| | |
| |
| |
| |
| | |
In my main commit I missed the scala doc annotation about not
being able to store null.
|
| |/
|
|
|
|
|
| |
This change adds a null sentinel object which is used to indicate that a null
value has been inserted in FlatHashTable. It also makes a strong distinction
between logical elements of the Set vs entries in the hash table. Changes
are made to mutable.HashSet and ParHashSet accordingly.
|
| | |
|
| |\
| |
| | |
SI-5767 fix + protecting public FlatHashMap API
|
| | | |
|
| | |
| |
| |
| | |
As discussed in https://groups.google.com/forum/?pli=1#!topic/scala-internals/1yABM30POS0
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
- Replaced/simplified usages of "wrt".
- Added backticks to $Coll definitions, so stuff like "immutable.Stack"
hopefully stops being interpreted as the end of a sentence and shown
like that in the summary line of ScalaDoc's method description.
See collection.immutable.Stack's sortBy.
Additionally, it looks nicer this way.
- Fixes the typo mentioned in SI-5666.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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].
|
| |
|
|
|
|
|
| |
The size map size computation for parallel hash sets was invalid.
No review.
|
| |
|
|
|
|
|
|
| |
the wrong places, tags saying the wrong thing. I sorted types and values
so deprecated ones are at the end. I think they should be hidden by
default, but this is a big improvement. Leaving #3914 open so they can
be made invisible. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removing toPar* methods, since we've agreed they're difficult to: -
underestand - maintain
Also, changed the docs and some tests appropriately.
Description:
1) Every collection is now parallelizable - switch to the parallel version of the collection is done via `par`.
- Traversable collections and iterators have `par` return a parallel
- collection of type `ParIterable[A]` with the implementation being the
- representative of `ParIterable`s (currently, `ParArray`). Iterable
- collections do the same thing. Sequences refine `par`'s returns type
- to `ParSeq[A]`. Maps and sets do a similar thing.
The above means that the contract for `par` changed - it is no longer guaranteed to be O(1), nor reflect the same underlying data, as was the case for mutable collections before. Method `par` is now at worst linear.
Furthermore, specific collection implementations override `par` to a more efficient alternative - instead of copying the dataset, the dataset is shared between the old and the new version. Implementation complexity may be sublinear or constant in these cases, and the underlying data structure may be shared. Currently, these data structures include parallel arrays, maps and sets, vectors, hash trie maps and sets, and ranges.
Finally, parallel collections implement `par` trivially.
2) Methods `toMap`, `toSet`, `toSeq` and `toIterable` have been refined
for parallel collections to switch between collection types, however,
they never switch an implementation from parallel to sequential. They
may or may not copy the elements, as is the case with sequential
variants of these methods.
3) The preferred way to switch between different collection types,
whether maps, sets and seqs, or parallel and sequential, is now via use
of methods `toIterable`, `toSeq`, `toSet` and `toMap` in combination
with `par` and `seq`.
Review by odersky.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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?
|
| |
|
|
|
|
|
| |
Added toParIterable, toParSeq, toParSet and toParMap conversions.
No review.
|
| |
|
|
|
| |
Review by extempore.
|
| |
|
|
|
|
|
|
|
|
|
| |
Added parallel mutable hash sets.
Implemented parallel mutable hash set iterators.
Implemented parallel mutable hash set combiners.
Factored out unrolled linked lists into a separate class UnrolledBuffer, added tests.
Added parallel mutable hash set tests, and debugged hashsets.
No review.
|
| |
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Created Mutable and Immutable SetFactories to deal with the spectacular
performance regression which accompanies the use of AddingBuilder on
mutable Sets. Because '+' now creates a new collection even on mutable
sets, AddingBuilder on a 100K element collection will create garbage
sets of size 1,2,3...,99,999 before finishing. Thankfully there is
already GrowingBuilder.
See test/files/run/adding-growing-set.scala for a demonstration.
This patch is not complete: in particular, SortedSet and SetBuilder need
attention. Unfortunately there is a combinatorial jump in the number of
Addable/Growable divisions which arises once one tries to accomodate
both Sorted signatures (taking an Ordering) and unsorted signatures, so
will come back to it after receiving counsel.
Review by odersky.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to BufferLike (++ and similar now create a new collection.)
Removed MapLikeBase. Annotated all the methods in mutable.{ Map, Set }
which mutated in-place in 2.7 to note that they create new
collections, and implemented same.
At this point the only +/- like method which mutates in place which I am
aware of is BufferLike.+ (see source comment for my observations.)
Also tweaked some collections return types as necessitated by these
changes, such as mutable.Set.clone() now returning "This" rather than
mutable.Set[A].
References #3089, closes #3179. Review by odersky.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[This patch submitted by ismael juma - commit message his words,
but condensed.]
Fix ticket #1600: Serialization and deserialization of hash-based
collections should not re-use hashCode. The collection is rebuilt
on deserialization - note that this is not compatible with the previous
serialization format. All @SerialVersionUIDs have been reset to 1.
WeakHashMap is not Serializable and should not be so. TreeHashMap has
not been reintegrated yet. OpenHashMap has not been updated. (I think
this collection is flawed and should be removed or reimplemented.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In "Iterable" and in all its subclasses, "iterator" replaces "elements"
(and assorted changes).
|
| |
|
|
|
|
| |
added SynchronizedMap; changed Set.put to Set.add, implemented
LinkedHashMap/Set more efficiently.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Removed redundant type parameter for class Builder
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Updated collection library
|
