summaryrefslogtreecommitdiff
path: root/src/library/scala/collection/GenTraversableOnce.scala
Commit message (Collapse)AuthorAgeFilesLines
* assorted typo fixes, cleanup, updating of commentsSeth Tisue2016-10-241-1/+1
| | | | | | just in time for Halloween. "boostrap" is definitely the most adorable typo evah -- and one of the most common, too. but we don't want to scare anybody.
* SI-9823 Collections perf: favor virtual call over instanceofJason Zaugg2016-08-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This avoids concurrent usages of collections in NUMA architectures from falling of a performance cliff due to an implementation detail of interface instanceof checks in HotSpot JVM. The VM contains a one element cache in the metadata of each class to record the most recent successful test for a interface. For example: classOf[Serializable].isAssignableFrom(classOf[Some[_]]) Would, in addition to returning `true`, set: classOf[Some[_]]._secondary_super_cache = classOf[Serializable] This is done to hide the fact that interface tests are O(N), where N is the number of inherited interfaces. This scheme is discussed in "Fast Subtype Checking for the HotSpot JVM" (Click, Rose) [1] However, if this cache repeatedly misses, not only are we exposed to the linear search of the secondary super type array, but we are also required to write back to the cache. If other cores are operating on the same cache line, this can lead to a significant slowdown ("cache thrashing"). This effect will by most (or only?) visible on multi socket machines. The pathological case is: scala> Iterator.continually(List(classOf[Product], classOf[Serializable])).flatten.take(100).map(intf => intf.isAssignableFrom(classOf[Some[_]])).count(x => x) res19: Int = 100 Which, if run on a multi-socket machine, should be much slower than: scala> (Iterator.continually(classOf[Product]).take(50) ++ Iterator.continually(classOf[Serializable]).take(50)).map(intf => intf.isAssignableFrom(classOf[Some[_]])).count(x => x) res20: Int = 100 This commit avoids a interface test in a hot path in the collections by instead using virtual dispatch to differentiate between IndexedSeqLike and other collections. HotSpot will still use some shared bookkeeping ("inline cache" [2]) at the callsites of this method, but these stabilize in the megamorphic usage and no longer force expensive cache line synchronization. [1] https://www.researchgate.net/publication/221552851_Fast_subtype_checking_in_the_HotSpot_JVM [2] https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
* SI-9624 Improve documentation for TraversableOnceStefan Zeiger2016-02-041-0/+20
| | | | | | | | | - Move the doc comment for `hasDefiniteSize` up from TraversableLike to GenTraversableOnce and improve it. - Add a note to `GenTraversableOnce.isEmpty` that implementations must not consume elements. - Clarify alternatives to subclassing TraversableOnce.
* Improve collections documentation and prefer () to {}vsalvis2015-10-271-25/+61
| | | | | | | | | - Remove some duplicate method documentation that is now inherited - Whitespace edits - Rewording of method docs - Clearer usage examples - tparam alignment for some usecase tags - Prefer () to { } for do nothing bodies
* Rename forall, exists and find predicate and operator params.Janek Bogucki2015-10-091-4/+19
| | | | | | | | | | | | Align parameters names to use p for predicates and op for combining operations. Based on #4760. Extended to include, - Tuple2Zipped - Tuple3Zipped - Either The original author was vsalvis.
* fix typo in scaladocAlessandro Lacava2015-03-241-2/+2
|
* cleanup @throws tags in library and reflectAntoine Gourlay2014-11-051-1/+1
| | | | | - there is no need for explicit links with [[ and ]] - there is no need for explicit backquoting
* Remove "will not terminate" from toStream docBrian McKenna2014-03-121-1/+0
| | | | | | It's at least not always true: scala> val example = Iterator.continually(1).toStream example: scala.collection.immutable.Stream[Int] = Stream(1, ?)
* Fixes #3330 with Scaladoc changes onlyJason Swartz2014-01-071-4/+4
|
* Collections library tidying and deprecation. Separate parts are listed below.Rex Kerr2013-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Cull extraneous whitespace.Paul Phillips2013-09-181-2/+2
| | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #2709 from yllan/fix-docsAdriaan Moors2013-07-101-2/+2
|\ | | | | Fix docs inconsistent (cmp -> ord).
| * Fix docs inconsistent (cmp -> ord).yllan2013-07-061-2/+2
| | | | | | | | The parameter name is 'ord', but mentioned in docs with 'cmp'.
* | SI-7614 Minimize the times of evaluation f in TraversableOnce.maxBy/minBy.yllan2013-07-061-0/+26
|/ | | | | | | | | | | | | In the previous implementation, maxBy/minBy will evaluate most of its elements with f twice to get the ordering. That results (2n - 2) evaluations of f. I save both the element and result of evaluation to a tuple so that it doesn't need to re-evaluate f on next comparison. Thus only n evaluations of f, that is the optimal. Note that the original implementation always returns the first matched if more than one element evaluated to same largest/smallest value of f. I document this behavior explicitly in this commit as well.
* Absolutized paths involving the scala package.Paul Phillips2013-05-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* SI-6811 Remove primitive widenings and /:\Simon Ochsenreither2013-01-171-13/+0
|
* Merge commit 'refs/pull/1574/head' into merge-210Paul Phillips2012-11-051-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * commit 'refs/pull/1574/head': (24 commits) Fixing issue where OSGi bundles weren't getting used for distribution. Fixes example in Type.asSeenFrom Fix for SI-6600, regression with ScalaNumber. SI-6562 Fix crash with class nested in @inline method Brings copyrights in Scaladoc footer and manpage up-to-date, from 2011/12 to 2013 Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013 SI-6606 Drops new icons in, replaces abstract types placeholder icons SI-6132 Revisited, cleaned-up, links fixed, spelling errors fixed, rewordings Labeling scala.reflect and scala.reflect.macros experimental in the API docs Typo-fix in scala.concurrent.Future, thanks to @pavelpavlov Remove implementation details from Position (they are still under reflection.internal). It probably needs more cleanup of the api wrt to ranges etc but let's leave it for later SI-6399 Adds API docs for Any and AnyVal Removing actors-migration from main repository so it can live on elsewhere. Fix for SI-6597, implicit case class crasher. SI-6578 Harden against synthetics being added more than once. SI-6556 no assert for surprising ctor result type Removing actors-migration from main repository so it can live on elsewhere. Fixes SI-6500 by making erasure more regular. Modification to SI-6534 patch. Fixes SI-6559 - StringContext not using passed in escape function. ... Conflicts: src/actors-migration/scala/actors/migration/StashingActor.scala src/compiler/scala/tools/nsc/backend/jvm/GenASM.scala src/compiler/scala/tools/nsc/settings/AestheticSettings.scala src/compiler/scala/tools/nsc/transform/Erasure.scala src/library/scala/Application.scala src/library/scala/collection/immutable/GenIterable.scala.disabled src/library/scala/collection/immutable/GenMap.scala.disabled src/library/scala/collection/immutable/GenSeq.scala.disabled src/library/scala/collection/immutable/GenSet.scala.disabled src/library/scala/collection/immutable/GenTraversable.scala.disabled src/library/scala/collection/mutable/GenIterable.scala.disabled src/library/scala/collection/mutable/GenMap.scala.disabled src/library/scala/collection/mutable/GenSeq.scala.disabled src/library/scala/collection/mutable/GenSet.scala.disabled src/library/scala/collection/mutable/GenTraversable.scala.disabled src/library/scala/collection/parallel/immutable/ParNumericRange.scala.disabled
| * Brings all copyrights (in comments) up-to-date, from 2011/12 to 2013Heather Miller2012-11-021-1/+1
| |
* | SI-6467: Zero element in aggregate now by-nameAleksandar Prokopec2012-10-041-2/+3
|/
* Eliminate breaking relative names in source.Paul Phillips2012-09-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Eliminated all the current feature warnings.Paul Phillips2012-07-271-0/+1
| | | | This pretty much takes us down to deprecation and inliner warnings.
* Renaming convertTo to to on GenTraversableOnce.Josh Suereth2012-06-281-2/+2
|
* Fixing embarassing typo.Josh Suereth2012-06-181-1/+1
|
* Migrate build to @odersky's suggestion of convertTo.Josh Suereth2012-06-181-2/+2
| | | | | | * Move method into TraversableOnce from Iterator and Traversable to make the build pass. * Udpate IDE tests with new collection methods. * Rewire default toXYZ methods to use convertTo.
* Rename copyTo to build based on consensus of 3Josh Suereth2012-06-181-2/+2
|
* Fixes from review.Josh Suereth2012-06-181-4/+4
| | | | | | * Fixed typo * Renamed copyInto to copyTo * Added tparam doc.
* Adding copyInto and toVector methods to collections.Josh Suereth2012-06-181-0/+19
| | | | | * Added generic copyInto method for collections. For any collection with a CanBuildFrom, can convert a generic collection into it using the builder. * Added specifici toVector method for collections. This is more efficient than copyInto if the collection is a Vector.
* removes array tagsEugene Burmako2012-06-081-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 2.10 we had a notion of ClassManifest that could be used to retain erasures of abstract types (type parameters, abstract type members) for being used at runtime. With the advent of ClassManifest (and its subtype Manifest) it became possible to write: def mkGenericArray[T: Manifest] = Array[T]() When compiling array instantiation, scalac would use a ClassManifest implicit parameter from scope (in this case, provided by a context bound) to remember Ts that have been passed to invoke mkGenericArray and use that information to instantiate arrays at runtime (via Java reflection). When redesigning manifests into what is now known as type tags, we decided to explore a notion of ArrayTags that would stand for abstract and pure array creators. Sure, ClassManifests were perfectly fine for this job, but they did too much - technically speaking, one doesn't necessarily need a java.lang.Class to create an array. Depending on a platform, e.g. within JavaScript runtime, one would want to use a different mechanism. As tempting as this idea was, it has also proven to be problematic. First, it created an extra abstraction inside the compiler. Along with class tags and type tags, we had a third flavor of tags - array tags. This has threaded the additional complexity though implicits and typers. Second, consequently, when redesigning tags multiple times over the course of Scala 2.10.0 development, we had to carry this extra abstraction with us, which exacerbated the overall feeling towards array tags. Finally, array tags didn't fit into the naming scheme we had for tags. Both class tags and type tags sound logical, because, they are descriptors for the things they are supposed to tag, according to their names. However array tags are the odd ones, because they don't actually tag any arrays. As funny as it might sound, the naming problem was the last straw that made us do away with the array tags. Hence this commit.
* removes tags and their incantations from PredefEugene Burmako2012-06-081-0/+2
| | | | | | All tags and reflection-related stuff requires a prefix, be it scala.reflect for simple tags (ArrayTags and ClassTags), or scala.reflect.basis/scala.reflect.runtime.universe for type tags.
* Address doc comment rot in the standard library.Jason Zaugg2012-05-131-12/+12
| | | | | | | | | | | | | | | | | | | | | - 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] ^
* Fixes SI-4478.Simon Ochsenreither2012-05-021-1/+1
| | | | | | | | | | - 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.
* migrates stdlib and compiler to tagsEugene Burmako2012-04-231-3/+3
| | | | | * all usages of ClassManifest and Manifest are replaced with tags * all manifest tests are replaced with tag tests
* Close issue #SI-4488Manohar Jonnalagedda2012-03-241-5/+5
| | | | | | The issue is closed as won't fix, but there are a few test cases with respect to the model relevant to the issue. Also, correct some typos.
* Lots of tedious warning and tree printing work.Paul Phillips2012-03-201-1/+1
| | | | | | | | | | | Fewer deprecation warnings, prettier trees, prettier symbols, more polished error messages. Oh the interesting people you meet handling warnings, I feel sorry for you all that I get to do it all the time. One of the characters I met invited me into the "Dead Code Society" and that's what I'm doing on Tuesdays now. No of course you haven't, it's a SECRET society.
* Adapted usecases to full signature displayVlad Ureche2012-03-201-20/+33
|
* Deprecating /:\. Fold should be used instead.Martin Odersky2012-02-121-0/+1
|
* A first bunch of Any-extending traits.Martin Odersky2012-02-061-1/+1
|
* intermediate work towards a new starr for value classes.Martin Odersky2012-02-031-1/+1
|
* Fixing redundant type parameter in toIndexedSeq which causes suboptimal type ↵Martin Odersky2012-01-101-1/+1
| | | | inference
* - Update Scaladoc for LinkedList and for some o...Paul Phillips2011-07-291-1/+40
| | | | | | | | | | - Update Scaladoc for LinkedList and for some of the functions/operators - that it inherits. Completed Scaladoc for append Added example - in GenSeqLike for apply. Added $collectExample to collect in - GenTraversableLike and supplied an actual example in LinkedList Contributed by Donald McLean.
* collection docs: fix copy-paste errors in GenTr...Paul Phillips2011-07-161-28/+14
| | | | | | | | | | | | | | collection docs: fix copy-paste errors in GenTraversableOnce In r24752, the documentation of reduce, reduceOption, fold, and aggregate were copied verbatim from ParIterableLike to the new GenTraversableOnceLike, and in r24786 they were brought along as GenTraversableOnce replaced GenTraversableOnceLike. Some bits of what they said were appropriate for ParIterableLike but are no longer appropriate here. Contributed by Greg Price.
* 2nd round of clean ups (see r25285)michelou2011-07-151-23/+27
|
* Made GenTraversableOnce public.Paul Phillips2011-05-071-1/+1
| | | | | No review.
* One of the blips in the performance charts seem...Paul Phillips2011-04-201-1/+1
| | | | | | | | | | One of the blips in the performance charts seems to implicate some changes I made with slice to reduce the number of implementations and surface area for inconsistencies and bugs. Altering those changes in a more performance-mindful way, although I don't see anything here which is likely to help much. Also fixing some wrong documentation about copyToArray. No review.
* Removed GenTravOnceLike and TravOnceLike, put t...Aleksandar Pokopec2011-04-191-2/+492
| | | | | | | | | Removed GenTravOnceLike and TravOnceLike, put their functionality to GenTravOnce and TravOnce. Remove immutable Gen* traits. Removing mutable Gen* traits. No review.
* Doing a little polishing on the parallel collec...Paul Phillips2011-04-141-5/+2
| | | | | | | | | | | | | Doing a little polishing on the parallel collections refactor (which overall looks like a big improvement.) I went for some simpler wording and moved a number of scaladoc tags around because the rug had been pulled out from under their feet. This leaves a lot undone, but since many of the docs need to be reworded before they can move from e.g. SeqLike to GenSeqLike, and I'm not well informed on exactly how these abstractions are being presented, I stayed in the safe zone. Review by prokopec.
* Refactoring the collections api to support diff...Aleksandar Pokopec2011-04-131-0/+23
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.