| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Don't crash the compiler for the 'companions in different files'
error. This turned out to be pretty bad for the presentation compiler.
References #1286. Review by extempore
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
your fp with no tolerance for tomfoolery, this is the commit for you.
Closes #1708, review by community.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
No review.
|
|
|
|
|
|
|
|
| |
Mostly refactored existing test functionality for parallel collections.
Added immutable hash set tests.
No review.
|
|
|
|
|
| |
No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A double goodness whammy involving type inference at the borders.
1) Implicit search preserves singleton type fidelity. 2) Unification of
parent bounds is (closer to) correct.
Result of 1: "implicit def f(x: Foo.type)" will convert object Foo.
Result of 2: "new Trait[Int] { }" may enjoy its type constructor being
inferred, no longer foiled by the anonymous class.
Also included are some clarity-enhnancing renamings and refactorings.
Performance note: I heavily benchmarked the change to isSubArgs and it
is reproducibly faster than the previous implementation. Numbers and
methodology available upon request.
Closes #2693, #3964. Review by moors, who wrote most of this patch but
might like to review the comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some uninteresting code related to error messages, which I'm checking
in mostly because I booted the r23379 commit in a git-svn meltdown and
posterity demands the message, which was:
You can now use the self-type of an anonymous class as a singleton type
in a pattern match ON THE MOON. Actual test case excerpt:
val x4 = new { self =>
def f(x: Any) = x match {
case _: x1.type => 1
case _: x2.type => 2
case _: x3.type => 3
case _: self.type => 4
case x: Dingus.type => x.IamDingus
}
}
Closes #576, no review.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Case accessors are always public else the pattern matcher goes south. A
more discriminating fix may be possible at some point, but it looks to
be an involved endeavor. Closes #3714, review by odersky.
|
|
|
|
|
|
| |
Added test for #3312 which it looks like was fixed long ago but not
closed. Closes #3312, no review.
|
|
|
|
|
|
|
| |
protected and its bevy of corner cases. Closes #3939, #3947. This patch
is intended for both trunk and 2.8.1. Already reviewed and co-authored
by moors, and review by oderksy.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the behavior on the IBM VMs is really funny. when running the scopes
test individually (using partest or ant), it succeeds. even when running
all the neg tests with ant it succeeds. but when running the whole test
suite, it fails.
no review.
|
|
|
|
|
|
|
| |
Plus one wild goose chase and test fixes.
No review.
|
|
|
|
|
|
|
|
| |
Some exception handling fixes in parallel collections. Fixed some
regressions. Fixed some tests.
No review.
|
|
|
|
|
| |
As hash codes change, so do the tests - output order for a HashMap is different now. No review.
|
|
|
|
|
|
|
|
| |
Closes #3059, #3895 (the only difference between this and r23232 is the
forced info transformation that ensures that nested objects are viewed
as lazy vals). sbt integration requires new starr for this commit to
work.
|
| |
|
| |
|
|
|
|
|
|
| |
Fix involving xml equality, contributed by mark harrah. Closes #3886, no
review.
|
|
|
|
|
|
|
|
| |
As pointed out to me by plocinic, the pattern matcher has been
indiscriminately clearing the MUTABLE flag on synthetic vals because it
is signalling itself with that bit and it didn't think anyone else would
ever notice. Someone did. Closes #3699, review by plocinic.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Closes #3934 by fixing a typo (missing + in string concat). Better
effect analysis would have caught that one at compile-time. Review by
extempore.
|
| |
|
|
|
|
|
|
| |
Reverted previous commit as I think it is wedging under -optimise. No
review.
|
|
|
|
|
|
|
|
| |
Made some changes to fjbg so when people run into #1133 at least it will
tell them what method was the cause. The fact that ten files are touched
in this commit instead of one or two is a testament to the wonder of
checked exceptions. 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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modification to the widening logic to treat locally defined symbols like
final members thus allowing more constants to be inlined. Concretely,
that means that in code like this:
def f: Unit = { val b = false ; if (b) println("ok") }
The call to println is no longer generated at all, and in this code:
def f(x: Int) = { val X = 1 ; val Y = 2; x match { case X => 1 ; case Y => 2 } }
A tableswitch is generated instead of the present if/then/else.
I also added a big comment to the former widenIfNotFinal (now
widenIfNecessary for obvious reasons.) Review by rytz.
|
|
|
|
|
|
| |
All this time with Nil only claiming to be equal to immutable.Seqs, how
is it possible? Closes #3923, no review.
|
| |
|
|
|
|
|
|
| |
Fixing issue with XMLEventReader.stop failing to stop the parser thread.
Contributed by Jean-Laurent Huynh, reviewed by extempore. Closes #3881.
|
|
|
|
|
|
|
|
|
|
|
|
| |
An object with a main method can now extend its companion class without
losing the ability to run. Also gave genjvm a wax and polish while in
the neigborhood. Closes #3487.
I had to get a little tricky with this one. No review per se, but if
anyone is frightened by the prospect of the forwarders not being marked
final in this case (because as of now, they aren't) then speak now or
ACC_FINAL hold your peace.
|