| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Type parameter names are currently assigned pretty much alphabetically
without any meaning. This change renames all key parameters in Map
classes from `A` to `K` and all value parameters from `B` to `V` to
make them more meaningful. Derived names are renamed accordingly (e.g.
`V1` instead of `B1` for an upper bound on `V`, `W` instead of `C` for
a new value type).
As a side-effect this solves the documentation problem in SI-6947. Due
to using `B` both as a type parameter for `foldLeft[B]` in
`GenTraversableOnce[A]` and in `Map[A, B]` which extends
`GenTraversableOnce[(A, B)]`, the signature of `Map.foldLeft` was
rendered in scaladoc as
def foldLeft[B](z: B)(op: (B, (A, B)) ⇒ B): B
Now you get an unambiguous version:
def foldLeft[B](z: B)(op: (B, (K, V)) ⇒ B): B
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes all first sentences of library functions which
contain `i.e.` or `e.g.` and adds a `,` to prevent that the scaladoc
summary sentence is cut after this abbreviation.
This is possible as pull/3824 fixed how Scaladoc parses the first
sentence of a method description into a sumary sentence(now the first
sentence has to end with a dot followed by whitespace).
Only docs in the core library are changed (src/library/**/*.scala)
and only if they occur in the first sentence.
Review by @heathermiller
(cherry picked from commit 72721ff5dd06dea1235ecb71acae0bd61aee4814)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some names I missed in 55b609458fd .
How one might know when one is done:
mkdir scratch && cd scratch
mkdir annotation beans collection compat concurrent io \
math parallel ref reflect runtime scala sys testing \
text tools util xml
scalac $(find ../src/library -name '*.scala')
Until recently that would fail with about a billion errors. When it
compiles, that's when you're done. And that's where this commit
takes us, for src/library at least.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move `MurmurHash3` to `util.hashing`.
Make the `class` private and retain a public companion
`object`, and put the `MurmurHash3.Hashing` implementations
for various types in the companion.
Add a method which composes `ByteswapHashing` with some other hashing.
Rename `hashOf` to `hash`.
Fix chi-square test in a test-case.
Review by @jsuereth.
Moved a failing test that seems to use some other library version to pending.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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] ^
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trying to make hashcodes faster. Didn't achieve much on that front, so
redirected into structural/consistency issues. The latter was lacking
in terms of how/where "def seq" was defined. The documentation I can
find doesn't give me much hint that the sequential form of my sequential
collection might be a single-use iterator! (As in StringOps, ArrayOps.)
If that's intentional it should be in huge letters. I'm assuming for now
that it wasn't.
Also, there was this:
GenMapLike: def seq: Map[A, B]
GenSetLike: def seq: Set[A]
GenSeqLike: // nothing, returns Traversable
So I added some def seqs where I needed the more specific types for
my hashcode work. Hashcodewise, I broke the MurmurHash3 object into
a reusable class and a collections-specific object, and I deprecated
the methods which took GenTraversableOnce in favor of ones taking
TraversableOnce, because there's no reason the hashcode library should
have to know about things like "make sure to call seq before you
traverse or you'll be sorry." Exclude things by their type and you can
never make a mistake. End transmission.
|
|
|
|
|
|
| |
Integrates recent speed improvements to algorithm.
Contributed by Ruediger Keller, no review.
|
|
|
|
|
| |
No review.
|
|
|
|
|
|
|
| |
Removing the package-private modifiers on Gen*Like traits.
No review.
|
|
|
|
|
|
|
| |
Also, added some docs variables to Gen* traits that were missing.
No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|