| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Don't let stringOf lose elements to print by hanging onto set semantics
for too long. Closes #3944, no review.
|
| |
|
|
|
|
|
|
|
|
| |
Achieved similar simplicity gains in NumericRange to those now in Range.
Obvious remaining task is to specialize NumericRange and after verifying
the performance, eliminate one or the other. For now, both soldier
onward despite near-convergence of implementation.
Closes #3232, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminated duplication among the Rich* wrappers, careful not to impact
performance on RichInt in particular. Attempted to make Proxy a little
bit typier. Proxy creates an asymmetric equals method by design so it's
unfixable in that regard, but achieved a minor miracle anyway by making
the Rich* wrappers behave symmetrically.
Note: said miracle involved having the wrappers extend ScalaNumber in
order to induce the special == semantics. This in turn led to implicit
conversion conflicts with the boxed types on methods like .intValue().
Resolved by moving the Rich* implicits into LowPriorityImplicits.
This of course also removed the intentional ambiguity which prevents
primitives from automatically becoming AnyRefs.
Solved THAT one by creating dedicated, laser-precise ambiguity creating
implicits in Predef which exclude only the AnyRef methods. Although
this is admittedly less than elegant, it is still better than it
was: this way it is direct and explicit rather than depending upon
the "implicit implicit conflict" where the barrier to promotion is
intermingled with the definitions of wrapper classes. (See the history
of BoxedUnit/RichUnit for a good example of why these concerns require
separation.)
It's all worth it:
assert(intWrapper(5) == 5)
assert(5 == intWrapper(5))
assert(5 == (5: java.lang.Integer))
assert((5: java.lang.Integer) == 5)
assert((5: java.lang.Integer) == intWrapper(5))
assert(intWrapper(5) == (5: java.lang.Integer))
Review by community.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all the boundary conditions I'm aware of, including not yet reported
ones such as
scala> 5 until 5 last
res0: Int = 4
and
scala> 1073741823 to Int.MaxValue by (1 << 24) size
res0: Int = 65
scala> 1073741823 to Int.MaxValue by (1 << 24) drop 100 size
res1: Int = 256
Also includes conformance improvements (e.g. 5 until 5 init should throw
an exception, not return empty) and general improvements (e.g. 1 to 10
tail should return a Range.) Will close associated tickets such as #3232
after I complete similar work on NumericRange. Review by community.
|
| |
|
|
|
|
|
|
|
|
| |
Performance bug in hash table splitter fixed, where size map was not
used and all the elements were counted instead.
Performance tests now pass.
No review
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
| |
Review by extempore.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
|
|
| |
foreach method in Tuple3, and both classes have what is now a redundant
zip method which is also unfortunately completely strict in a not
entirely fixable fashion. So "zip" is deprecated in favor of zipped.
Closes #3526, but the code which closes that is primarily found in
r23228. No review.
|
| | |
|
| |
|
|
|
|
|
| |
Plus one wild goose chase and test fixes.
No review.
|
| |
|
|
|
| |
No review
|
| |
|
|
|
|
|
|
| |
Some exception handling fixes in parallel collections. Fixed some
regressions. Fixed some tests.
No review.
|
| |
|
|
|
|
|
|
|
|
|
| |
Changed HashTable interface.
Fixed one test.
Implemented hash map iterators.
Implementing hash map combiners.
Extracting common functionalities of bucket-based combiners.
No review.
|
| | |
|
| |
|
|
|
| |
Changed hash code strategy in hash table - now taking most significant bits when transforming the hash code into an index.
|
| | |
|
| |
|
|
|
|
| |
Refactoring certain tasks to accept empty splitters. Adding parallel
mutable hash maps. No review
|
| |
|
|
|
|
| |
Fix involving xml equality, contributed by mark harrah. Closes #3886, no
review.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Documentation being generated by genprod was pretty busted both in terms
of formatting and correctness. Spruced it up. Eliminated some of the
more distracting HTML entities in compiler source. No review.
|
| |
|
|
|
|
|
|
|
|
| |
Disambiguated all the implicits in JavaConversions. All the
documentation had fallen out of date so I fixed that up too, in the
process converting from HTML to wikiformatting. (Wouldn't it be nice to
mass convert trunk out of the HTML tags?)
Closes #3688, no review.
|
| | |
|
| |
|
|
|
|
| |
All this time with Nil only claiming to be equal to immutable.Seqs, how
is it possible? Closes #3923, no review.
|
| |
|
|
|
|
|
|
| |
re-added isAbstract and isTrait to HasFlag because sbt build breaks
otherwise (compiler-interface accesses Modifiers.isAbstract). note that
the sbt build still doesn't work right now because of a bug in r23232.
hubert is working on that. review by extempore.
|
| |
|
|
|
|
| |
Fixing issue with XMLEventReader.stop failing to stop the parser thread.
Contributed by Jean-Laurent Huynh, reviewed by extempore. Closes #3881.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added filterNot to Option so I can stop being driven mad by this
difference.
scala> Some(5) filter (_ > 2)
res0: Option[Int] = Some(5)
scala> Some(5) filterNot (_ < 2)
res1: Iterable[Int] = List(5)
No review.
|
| |
|
|
|
|
|
|
|
|
|
| |
into Modifiers and Symbol, but touches as little as possible beyond
that. It also includes some lengthy commentary (see HasFlags.scala) on
the state of the flags and some of the remaining issues. One more patch
which unfortunately but unavoidably touches almost every file in the
compiler lies ahead.
The floor is still open! But no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
toString when constructing the exception: it need not be called
until/unless it is printed, which it may never be. 2) Include the name
of the class which triggered it. Don't tell me you haven't wanted that
as many times as I have.
(Sidebar on commit message semantics: I assume nobody interprets "no
review" to mean anything like "unreviewable decision!" It only means I'm
pretty sure the code does what I intended. The floor is always open.)
That said, no review.
|
| |
|
|
|
|
| |
Encapsulating name strings in StdNames and eliminating misc duplication.
No review.
|
| |
|
|
|
|
|
|
| |
contributed by "archontophoenix", following in the grand tradition of
code by people whose actual names I don't know. References #2537, but it
doesn't close until some sensible hashcode is used by default. Review by
community.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An overhaul of the collection-oriented methods in Tuple2/Tuple3 (which
still need to be taken all the way to Tuple5.)
* Zip semantics: zip and zipped now properly terminate when any
collection runs out of elements, even if others are infinite. In
addition, short circuiting methods (exists and forall) will terminate if
the condition is met, even in the presence of infinity.
Example:
scala> val ys = Stream from 1
ys: scala.collection.immutable.Stream[Int] = Stream(1, ?)
scala> (ys, ys).zipped forall ((x, y) => x+y < 100)
res0: Boolean = false
scala> (ys, ys).zipped exists ((x, y) => x+y > 100)
res1: Boolean = true
* There are implicits converting Zipped2/3 to Traversable to expose all
the methods which aren't defined in an arity-specific way in the tuple
classes. I have mixed feelings about putting these in Predef; but if
there is another way to make them visible by default I wasn't able to
find it.
Example putting said implicit to use:
scala> (ys, ys, ys).zipped find { case (x, y, z) => x+y+z > 1000 }
res0: Option[(Int, Int, Int)] = Some((334,334,334))
Already reviewed by moors, so no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Abstracting out the common flags code between Symbol and Modifiers
into HasFlags. This patch includes only the non-invasive changes: the
HasFlags trait is not integrated into those classes. The remainder is
complete but I'm checking this part in case anyone would like to throw
some feedback my way at this point: general comments, or the open issues
noted in comments in HasFlags.scala.
This commit also eliminates the (now unused) MONOMORPHIC flag and
includes utility methods for reflective analysis of a Flags object which
generate code and comments based on the accessors found. See the comment
at the top of symtab.Flags and the flagToString implementation in that
class for illustration.
I haven't tested the very latest, but a slightly older incarnation
without material differences showed no measurable performance change.
No specific review, but comments welcome.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Made some adjustments to toString formatting of JSON
Closes #3605
Hopefully this is the last time I have to close this ticket. In addition
to default behavior, the end user can specify their own JSON value
formatting function if they want to customize it.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Fixing an issue with hashset splitters where the splitting does not work
if some elements have already been iterated. Added parallel collections
exception handling. Added parallel collections break control. Renaming
ParHashTrie -> ParHashMap.
The part with immutable.{HashSet, HashMap} - review by rompf
|
| |
|
|
|
|
| |
Reverts r23174, which I believe will bring the build back to life. It
only chokes under -optimise. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
patches for #3887 and #3888, but I determined that I could achieve the
same effect by deleting a bunch of code, so I did. This left only a few
lines in TransMatch, so I eliminated it, which led me to remember that
many places still reference non-existent phase transmatch, so those were
updated. Notes:
* This swaps equality tests on stable identifier patterns. They
have never conformed to the spec (as noted long ago in ticket #785)
which says "The pattern matches any value v such that r == v" whereas
until now the test being performed was v == r.
* An issue was introduced with specialization in that the implementation
of "isTupleType" in Definitions relied upon sym == TupleClass(elems.length).
This test is untrue for specialized tuples, causing mysterious behavior
because only some tuples are specialized. There is now "isTupleTypeOrSubtype"
although it seems likely the former implementation is unnecessary.
The issue is sidestepped if one uses "getProductArgs" to retrieve the element
types because it sifts through the base types for the Product symbol.
Closes #3887 and #3888, review by dmharrah.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removes a bunch of private functions which are never called. While based
on the nature of "private" one can generally feel pretty good that such
a thing is safe, there is always a chance the author had some future use
in mind. On that note I draw your attention in particular to:
(martin) Typers#stabilizedType: it "sounds" important, but most of it
has been commented out since 2007 and the little stub part is a never
called private.
(iulian) SpecializeTypes#makeTypeArguments: similarly sounds like a
cornerstone of a transformation until one notices it isn't used.
Unused methods are "attractive nuisances" for anyone (like myself) who
has to figure out how the compiler works by studying the compiler, for
reasons which are no doubt obvious. No review except as noted.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
