summaryrefslogtreecommitdiff
path: root/src/library/scala/collection/mutable/History.scala
Commit message (Collapse)AuthorAgeFilesLines
* Typo and spelling correctionsJanek Bogucki2016-11-111-1/+1
|
* 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.
* More explicit empty paren lists in method calls.Jason Zaugg2013-02-241-3/+3
|
* Updated copyright to 2013Carlo Dapor2013-01-021-1/+1
|
* Third collections commit from Todd Vierling.Paul Phillips2011-11-071-1/+5
| | | | | | | Misc cleanups associated with the previous commits: limiting overly expanded types, fixing externally visible types for scaladoc, utilizing abstract collection classes where possible, etc.
* Dropped about 1.5 Mb off scala-library.jar.Paul Phillips2011-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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].
* Updated copyright notices to 2011Antonio Cunei2011-01-201-1/+1
|
* Deprecated the @serializable annotation, introd...Lukas Rytz2010-11-301-2/+1
| | | | | | | | | | | | | | | | | | | 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?
* Some minor fixes found by findbugs. No review.Paul Phillips2010-11-111-0/+1
|
* Removed more than 3400 svn '$Id' keywords and r...Antonio Cunei2010-05-121-1/+0
| | | | | Removed more than 3400 svn '$Id' keywords and related junk.
* More docs. No review.Aleksandar Pokopec2010-04-101-6/+10
|
* Updated copyright notices to 2010Antonio Cunei2009-12-071-1/+1
|
* Simplifiations in collections libraries, enable...Martin Odersky2009-11-201-6/+6
| | | | | | Simplifiations in collections libraries, enabled by introduction of Self type in TraversableLike.
* add @since annotationsstepancheg2009-09-261-0/+1
|
* Collections refactoring.Martin Odersky2009-09-251-1/+2
|
* fixed headers/comments/svn props, made some pro...michelou2009-09-151-2/+12
| | | | | | fixed headers/comments/svn props, made some progress with serializable classes
* Handled a dozen or so deprecation warnings.Paul Phillips2009-08-191-1/+1
|
* In "Iterable" and in all its subclasses, "itera...Gilles Dubochet2009-05-271-2/+2
| | | | | | In "Iterable" and in all its subclasses, "iterator" replaces "elements" (and assorted changes).
* Not quite complete reintegration of a handful o...Paul Phillips2009-05-271-11/+6
| | | | | | | | Not quite complete reintegration of a handful of collection classes, but they compile quietly and keep to themselves (of course that's always what the neighbors say after some loner goes on a rampage, so it's not the innocuous description it once was.)
* massive new collections checkin.Martin Odersky2009-05-081-0/+2
|
* Updated (all) copyright notices to 2009Antonio Cunei2009-01-131-1/+1
|
* Checking in everything else to fix the build!Sean McDirmid2007-04-031-2/+2
|
* Removed Pair(...), Triple(...).Martin Odersky2007-02-211-5/+5
|
* updated annotations in Scala librarymichelou2007-02-201-3/+3
|
* changed tuple syntax to (...)Martin Odersky2007-02-131-5/+5
|
* changed pair(...) to {...}Martin Odersky2007-02-051-5/+5
|
* fixed problems with build.Martin Odersky2007-01-221-1/+1
|
* improved comments in scala/collection/*.scalamichelou2006-10-111-0/+4
|
* removed leading/trailing tabs/blanks in collect...michelou2006-10-041-12/+12
| | | | | removed leading/trailing tabs/blanks in collection/mutable/*.scala
* Rearranged header and updated copyright messagemihaylov2006-03-021-2/+4
|
* Switching to the new build system and to the ne...Gilles Dubochet2005-12-191-0/+42
Switching to the new build system and to the new build system. This is a MAJOR commit, so be careful when updating.