| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Fixed bug in IndexedSeqOptimized.indexWhere such that the empty string
would find things all over the place. Closes #4197, no review.
|
|
|
|
|
|
| |
A few minor hashcode tidbits I had stored away from previous hashcoding,
and some fixups in treedsl. No review.
|
|
|
|
|
|
| |
Conflicts:
src/library/scala/concurrent/SyncVar.scala
|
|
|
|
|
|
|
| |
SyncVar should not swallow interrupts and should be robust against
spurious wakeups. Closes #4094, review by prokopec. (What did you mean
in your comment that it is vulnerable against the take method?)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new murmur3 hashcode implementation contributed by rex kerr. I'm
really happy with it. There is benchmarking code included but you can
use the pudding for proof: the compiler compiling itself is clearly
faster. I deleted the existing murmur2 implementation which has never
left trunk in a release.
There remain some possible points of improvement with inlining and/or
synthetic method generation, but this is a major improvement over the
status quo. Closes #2537, review by prokopec.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AnyVal types become source files instead of polite compiler
fictions.
!! You'll need a serious "ant all.clean" now. !!
As of this commit the system is fully bootstrapped and the
synthetic code eliminated: only the source files remain. The
sort-of-AnyVal-companions in scala.runtime.* have all been eliminated
because the actual companions can do everything; deprecated vals in
the scala.runtime package object point to the companions. This left
AnyValCompanion as the only AnyVal related thing in the runtime package:
that made little sense, so I deprecated and moved it as well.
Starr is based on r24066 plus this commit. Closes #4121. Review by rytz,
odersky.
|
| |
|
|
|
|
|
|
|
| |
The empty string commit made me hungry to actually know what's in stuff.
Now it prints quotes around a string if it's empty or if either the
first or last character is whitespace. No review.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Integrated contributed non-recursive implementation of permutations,
combinations, subsets, by EastSun. Also gave mutable Seqs an in-place
transform method like the one Map has. And couldn't resist slightly
reformulating a few set methods, because how can we settle for
"forall(that.contains)" when we could have "this forall that". (Which is
also what normal people hear when we talk about sets.)
Closes #4060, #3644, review by moors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Made the empty string print as "" in the repl instead of as nothing.
This after being misled one too many times by a variation of this:
scala> List[String]()
res1: List[String] = List()
scala> List[String]("")
res2: List[String] = List()
No review.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introduce NullaryMethodType to disambiguate PolyType
motivation:
given `def foo[T]: (T, T)` and `type Foo[T] = (T, T)`,
`foo.info` and `TypeRef(_, Foo, Nil).normalize` are both
`PolyType(List(T), Pair[T, T])`
uncurry has been relying on an ugly hack to distinguish these
cases based on ad-hoc kind inference without this distinction,
the type alias's info (a type function) would be transformed to
`PolyType(List(T), MethodType(Nil, Pair[T, T]))`
anonymous type functions are being used more often (see #2741, #4017,
#4079, #3443, #3106), which makes a proper treatment of PolyTypes more
pressing
change to type representation:
PolyType(Nil, tp) -> NullaryMethodType(tp)
PolyType(tps, tp) -> PolyType(tps, NullaryMethodType(tp)) (if the polytype denoted a polymorphic nullary method)
PolyType(Nil, tp) is now invalid
the kind of a PolyType is * iff its resulttype is a NullaryMethodType or a MethodType (i.e., it's a polymorphic value)
in all other cases a PolyType now denotes a type constructor
NullaryMethodType is eliminated during uncurry
pickling:
for backwards compatibility, a NullaryMethodType(tp) is still pickled as a PolyType(Nil, tp),
unpickling rewrites pre-2.9-pickled PolyTypes according to the expected kind of the unpickled type (similar to what we used to do in uncurry)
a pickled PolyType(Nil, restpe) is unpickled to NullaryMethodType(restpe)
a pickled PolyType(tps, restpe) is unpickled to PolyType(tps, NullaryMethodType(restpe)) when the type is expected to have kind *
the rewrite probably isn't complete, but was validated by compiling
against the old scalacheck jar (which has plenty of polymorphic nullary
methods) nevertheless, this commit includes a new scalacheck jar
summary of the refactoring:
* PolyType(List(), tp) or PolyType(Nil, tp) or PolyType(parms, tp) if params.isEmpty ==> NullaryMethodType(tp)
* whenever there was a case PolyType(tps, tp) (irrespective of tps isEmpty), now need to consider the
case PolyType(tps, NullaryMethodType(tp)); just add a case NullaryMethodType(tp), since usually:
- there already is a PolyType case that recurses on the result type,
- the polytype case applied to empty and non-empty type parameter lists alike
* tp.resultType, where tp was assumed to be a PolyType that represents a polymorphic nullary method type
before, tp == PolyType(tps, res), now tp == PolyType(tps, NullaryMethodType(res))
* got bitten again (last time was dependent-method types refactoring)
by a TypeMap not being the identity when dropNonConstraintAnnotations
is true (despite having an identity apply method). Since asSeenFrom
is skipped when isTrivial, the annotations aren't dropped. The
cps plugin relies on asSeenFrom dropping these annotations for
trivial types though. Therefore, NullaryMethodType pretends to
never be trivial. Better fix(?) in AsSeenFromMap: `if(tp.isTrivial)
dropNonContraintAnnotations(tp) else ...`
TODO: scalap and eclipse
review by odersky, rytz
|
|
|
|
|
|
|
| |
What is, I think, the only possible solution to bug #4158 given the
current ways of controlling implicits. Let's just be glad there's one
instead of zero. Closes #4158, review by moors.
|
|
|
|
|
|
| |
A few bits of java code which use "" + x and can't be helped out by
scala compiler optimizations. No review.
|
|
|
|
|
| |
Reverted to curried invokeDynamic to fix a problem in typers.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
significantly faster. Closes #4006.
And, then I started trying to deal with some fundamental Manifest issues
and give it a little documentation. I left a trail of bloody comments,
for which I solicit review by moors.
|
| |
|
|
|
|
|
|
|
|
| |
Some modifications to @elidable: for reasons lost to me now it had a
default value such that annotated methods might be elided even if the
option wasn't given. It now does nothing in that situation. Closes
#4051, #4151, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imported sbt.Process into trunk, in the guise of package
scala.sys.process. It is largely indistinguishable from the version in
sbt, at least from the outside.
Also, I renamed package system to sys. I wanted to do that from the
beginning and the desire has only grown since then. Sometimes a short
identifier is just critical to usability: with a function like error("")
called from hundreds of places, the difference between system.error and
sys.error is too big. sys.error and sys.exit have good vibes (at least
as good as the vibes can be for functions which error and exit.)
Note: this is just the first cut. I need to check this in to finish
fixing partest. I will be going over it with a comb and writing
documentation which will leave you enchanted, as well as removing other
bits which are now redundant or inferior. No review.
|
|
|
|
|
|
| |
Make scala.collection.immutable.Set1, .Set2, Set3, Set4 constructors
private to the collection package. Closes #2845. No review.
|
| |
|
|
|
|
|
|
|
|
| |
Pulled some bit level operations into their own file. It's pretty much
impossible to abstract across Int and Long with no penalty, but we
can at least have duplicated code in the same place to minimize the
challenge. No review.
|
|
|
|
|
|
|
|
|
| |
I had closed #2441 as a duplicate of that, but unfortunately #4114 did
not bring #2441 along with it. Then I realized I'm a programmer, not a
helpless trac watcher. As is often the case with thes things, fixing
that revealed a bug in the library. Closes #2441 for real, review by
odersky.
|
| |
|
|
|
|
|
| |
No review.
|
|
|
|
|
| |
No review.
|
|
|
|
|
| |
No review.
|
|
|
|
|
| |
No review.
|
|
|
|
|
|
|
|
|
|
|
| |
scala> implicitly[CanBuildFrom[String, Int, List[List[Int]]]]
<console>:10: error: Cannot construct a collection of type
List[List[Int]] with elements of type Int based on a collection of type
List[List[Int]]. implicitly[CanBuildFrom[String, Int, List[List[Int]]]]
^
No review.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #3984 by the most arduous and indirect route imaginable:
abstracts the common code out of the TrieIterators in HashMap and
HashSet. When I raised this flag to find out if anyone would open
fire, all was quiet on the western front. Although I wouldn't want
to write code like this as an everyday thing, I think it serves as a
nice showcase for some of the abstraction challenges we're up against:
performance looks the same and I will never again have to fix the same
bug in two places. Review by rompf.
|
|
|
|
|
|
| |
The ensuring methods should be by-name on the message argument like
assert, assume, and require. Closes #4129, no review.
|
|
|
|
|
|
|
|
|
| |
Override checks and self-types still needed some work (ticket #2808.)
I believe this is the right change. The modifications in parallel and
actors were a result of the files failing to compile after the change to
allOverriddenSymbols. (I am taking the position that that aspect is a
feature.) Review by malayeri, odersky.
|
| |
|
|
|
|
|
|
|
|
| |
Implemented a (slower) workaround for parallel vectors. Implemented
group by.
No review.
|
|
|
|
|
| |
No review.
|
|
|
|
|
|
|
| |
Renamed the files whose names have fallen out of sync with their
contents thereby consigning us to ant's version of groundhog day. No
review.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoids the creation of an amazing 106,700,793 empty arrays (I counted
on my fingers) during the compilation of quick.lib and quick.comp by
reusing an empty Array[Object]. (And another ten million or so after
quick.comp, but who is counting.) It sounds like it would make a bigger
difference than it does. Also eliminated some strange indirection from
WrappedArray to LowPriorityImplicits back to WrappedArray on each
creation.
Review by dragos.
|
|
|
|
|
|
|
| |
De-finalized equals/hashCode on Trees so people ill-advisedly creating
custom Trees with non-reference equality can continue doing their
ill-advised thing. No review.
|
| |
|
|
|
|
|
| |
Towards a replay framework for the presentation compiler
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|