| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
Reverts r23174, which I believe will bring the build back to life. It
only chokes under -optimise. No review.
|
| |
|
|
|
|
| |
Another batch of busywork shuffling the contents of pending around. Can
almost see some daylight. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pattern matching on Array types, working for reals.
def f[T](a: Array[T]) = a match {
case x: Array[Int] => x(0)
case x: Array[Double] => 2
// etc.
}
I'd also like to thank "instantiateTypeVar" for displacing the
mechanical spiders and giant squid beings which used to fill my
nightmares. Now that I know true horror, I welcome the squid.
Closes #2755, review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The next batch of tests put up a little more struggle, but only a
little. See test/pending/pos/unappgadteval.scala (the changes for which
were in the previous commit) for an example of a test which might be on
to something. Any idea what it would take to get it working?
// the key lines
case i @ Suc() => { (y: Int) => y + 1 } // a = Int => Int
case f @ Lam[b,c](x, e) => { (y: b) => eval(e, env.extend(x, y)) } // a = b=>c
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sorting through the tests in pending from oldest to newest because I
don't believe in having useless appendages. The verdict on the oldest
fifteen tests is: 15/15 are fixed. Many were already in files under a
different name. I moved a few and deleted the rest. Fun fact of the
day: apparently there was a time when to call into java varargs with no
arguments you might have to write something like:
getClass().getMethod("getCount", Array[java.lang.Class[T] forSome { type T }]())
On this basis I retract any complaints I've ever had about anything.
There is one question mark outlined in pos/testCoercionThis.scala, a
file formerly called pos/moors.scala and therefore... review by moors.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Still giddy with the thrill of fixing #266, I vanquish another pattern
matcher bug from the dawn of time. If you've always wanted to write code
like this:
class Bob[K[_]] {
def foo(other: Any) = other match {
case x: (Bob[X] forSome { type X[_] }) =>
}
}
Now is your chance. Closes #1427, review by moors. (Is there a better
way to "shake off" the pattern existential?)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
situations where a mutable var will later be lifted. As a point of
interest, this bug reveals itself fairly clearly if you use a build
since r23112 and run the checker thusly:
scalac -d /tmp -Ycheck-debug -Ycheck:icode -Xprint:icode
test/files/run/bug3855.scala
It dies with the following explanation:
Output changed for Block 3 [S: 2] [P: 1, 4]
Exception in thread "main" scala.tools.nsc.backend.icode.CheckerException:
Incompatible stacks: TypeStack() and TypeStack(2 elems) {
REFERENCE(class IntRef)
REFERENCE(class IntRef)
} in Test.main at entry to block: 2
And indeed that was the source of the reported verifyerror.
Review by i. dragos.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refined crash avoidance related to self type tests in anonymous classes
as introduced for #576. Now it really only excludes anonymous classes.
Suddenly, this works:
override def equals(other: Any) = other match {
case _: this.type => true
case _ => false
}
Who will be the first to roll out some reference equality in the
this.type style? No review.
|
| |
|
|
|
|
| |
Fixed an ancient crasher in explicitouter involving singleton
self-types. Closes #266, review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
| |
including "CheckEither", written against scalacheck 1.2 in the year 471
AD. Removed all the duplicates I could find, mostly between pending
and files. Renamed a bunch of tests so they wouldn't look like likely
duplicates next time around. Nominated somebody else to do this once in
a while.
No review.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
closes #3857: retain pre-erasure info in type history after cloning of
mixed in members and, specifically for this bug, fields, so that java
generic type sigs are more precise.
review by DRagos
|
| |
|
|
|
|
| |
Added an override to immutable.IndexedSeq#toIndexedSeq which returns
itself. Closes #3732, no review.
|
| | |
|
| |
|
|
|
| |
Test case submitted by mark harrah closes #2813, no review.
|
| | |
|
| |
|
|
|
|
| |
Tail recursive implementation of mapConserve, submitted by Eric
Willigers. Closes #2411, review by malayeri.
|
| | |
|
| |
|
|
|
|
| |
Fixed an issue with ListSet getting confused about what goes forward and
what goes backward. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restoring negative literal parsing behavior to what should be the least
surprising option. Thanks much to Johannes Rudolph for identifying the
bug in the bytecode generator which needed addressing for us to arrive
at proper -0.0 behavior, and for writing the majority of this patch.
A '-' followed immediately by either a number or a period should now
always be treated as a single numeric literal, which means the minus
binds more tightly than anything else. A specific example of how this
differs from 2.8 final is:
-5.+(10) == 5.0 // and not -15.0
The full range of potentially ambiguous parses involving prefix
operators, numbers, and dots is quite large and still needs to be
completely and clearly specified.
Closes #2378 and #3657, review by odersky, jrudolph.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tweaks to ListSet to make it less pathological in its outlook. We
can see some modest improvements in run time and answer quality via the
enclosed test case:
// with this patch: 2.250s elapsed, assertions pass.
// without this patch: 51.441s elapsed, and it's
a mercy killing: java.lang.StackOverflowError at
scala.collection.immutable.ListSet$Node.contains(ListSet.scala:117) at
scala.collection.immutable.ListSet$Node.contains(ListSet.scala:117)
Closes #3822, review by community.
|
| |
|
|
|
|
|
| |
Does what can probably be done about strange iterator exhaustion
behavior. Maybe we should start thinking about iteratees... Closes
#3760, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
closes #1569, #3731: refactored dependent method types to get rid of
debruijn indices and use singleton types instead.
this is the core of the dependent types refactoring, no implicit or
inference changes
(one baffling discovery: resultType should drop annotations that don't subclass TypeConstraint, even in the trivial case... wow -- thanks to Tiark for helping me figure it out on a terrace in Barcelona
TODO: probably need a more principled approach to the propagation of plugin type-annotations)
review by odersky
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the Transform-derived traits within view resisted evaluating the entire
sequence on a toString call, but the original view returned from a call
to .view did not. This has a particularly bad result in the case of
Stream, as for instance:
Stream from 1 view
would enter infiniteloopiland in the repl despite the fact that it
should be doubly resistant to eager evaluation.
Review by prokopec.
|
| |
|
|
|
|
|
| |
[Editorial correction: r23000 was submitted by Johannes Rudolph and my
name inadvertently replaced his in the windy path from git to svn. The
comments and code are his. Posterity, take note!]
|
