| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Fixed adriaan's patch for type constructor inference. The problem with
haranguing people in bars about bugs is that the fixes with which they
provide you may be flawed. Fortunately moors has this novelist on
retainer. Review by moors.
|
| |
|
|
|
|
| |
Reverting recent type constructor patch until I can see why scalacheck
is getting blinkered by it. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed a big bug in type constructor unification caused by considering
only the parents rather than all the base types. This fix is a testament
to the power of haranguing people in bars when you are deeply offended
by a bug, like someone was by this one:
def f[CC[X] <: Traversable[X]](x: CC[Int]) = ()
f(1 to 5) // did not compile! Fear not, it does now
Review by moors.
|
| |
|
|
|
|
|
| |
prohibit case-to-case inheritance instead of issuing warning. closes
#4109. review by extempore, since it should make your life much easier
in the pattern matcher
|
| | |
|
| |
|
|
|
|
| |
Bounded wildcard types arising during pattern type inference can cause
unnecessary crashes. Closes #1048, review by odersky.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed a bug in the optimizer which was preventing private methods from
being inlined. Also relaxes a condition related to the "liftedTry"
problem: the inliner has to exclude certain methods from consideration
if there is a value on the stack and the method being inlined has
exception handlers. The new condition is as before, except that it does
not exclude methods of the "try/finally" variety (i.e. finalizers, but
no other exception handlers.) This is necessary to optimize this common
pattern:
@inline private def foo(body: => Unit) {
val saved = something
try body
finally something = saved
}
The closure for "body" can be fully eliminated, but only if the contents
of foo can be inlined into the caller.
Closes #4764, review by rompf.
|
| |
|
|
|
|
| |
evalOnce needs to pack the type before using it on new valdefs to avoid
existential mismatches. Closes #3960, review by moors.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
slight improvement to lubList so that the simple case of lubbing type
constructors works. review by extempore
the strategy is to detect when the ts in lub(ts) are actually type
constructors and remember their type parameters the BTS of a type
constructor is a list of proper types (the type constructors have been
applied to their dummy arguments, which are simply type refs to the
original type parameters) in lubList, we undo this damage by stripping
these dummy arguments (they refer to type parameters that are meant to
be bound)
a better fix would be to actually bind those type parameters that
appear free in error, but that would require major changes to the BTS
infrastructure
example that only kindasorta works now...
given:
trait Container[+T]
trait Template[+CC[X] <: Container[X]]
class C1[T] extends Template[Container] with Container[T]
C1's BTS contains Template[Container] with Container[T], but that
should really be [T] => Template[Container] with Container[T]
instead of wrapping it in a polytype, the current approach uses
elimHOTparams to patch up this type so that it looks more like a type
ctor: Template[Container] with Container, but this is ill-kinded as
Template[Container] is a proper type, whereas Container is not
the performance impact should be minimal, but caveat reviewer
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
possible, just far enough to avoid all kinds of undesirable consequences
which accompany the preservation of too much type information. (The
problems are akin to inferring the singleton type too freely.)
// Example of code which did not compile, but now does class A class
B[T <: A](cons: T)
object C extends B(new A {})
Closes #4110, #3048. I already ran this by moors, so review by odersky.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added sanity check to lub calculation to prevent invalid lubs from
emerging. The underlying cause of said lubs is that higher-order
type parameters are not handled correctly: this is why the issue
is seen so frequently in the collections. See pending test
pending/pos/those-kinds-are-high.scala for a demonstration. Until that's
fixed, we can at least raise the bar a bit.
Closes #2094, #2322, #4501. Also, some test cases in neg have been
promoted into working programs: #2179, #3774. (They're not in neg for
the "shouldn't work" reason, but out of despair.)
In some cases, such as the original reported ticket in #3528, this
only pushes the problem downfield: it still fails due to inferred type
parameters not conforming to bounds. I believe a similar issue with
higher-order type parameters underlies that.
Look at how far this takes us though. All kinds of stuff which did not
work, now works. None of these even compiled until now:
scala> :type List(mutable.Map(1 -> 1), immutable.Map(1 -> 1))
List[scala.collection.Map[Int,Int]]
scala> :type Set(List(1), mutable.Map(1 -> 1))
scala.collection.Set[Iterable[Any] with PartialFunction[Int,Int]]
scala> :type Stream(List(1), Set(1), 1 to 5)
Stream[Iterable[Int] with Int => AnyVal{def getClass(): Class[_ >: Int with Boolean <: AnyVal]}]
scala> :type Map(1 -> (1 to 10), 2 -> (1 to 10).toList)
scala.collection.immutable.Map[Int,scala.collection.immutable.Seq[Int]
]
PERFORMANCE: compiling quick.lib and quick.comp, this patch results in
an extra 27 subtype tests. Total. Time difference too small to measure.
However to be on the safe side I made it really easy to disable.
private final val verifyLubs = true // set to false
Review by moors, odersky.
|
| |
|
|
|
|
|
|
| |
Notice when erasure is trying to cast something to Unit, and don't
do it. I'm not sure at what prior point such things should have been
caught, but for now we can have a sanity check. Closes #4731, review by
odersky.
|
| |
|
|
|
|
|
|
| |
Relaxes a typer check which fails valid code with NoCommonType. If the
instantiated types or type bounds do not conform, it tries normalizing
the type before throwing the exception. Closes #4553. I wrote this patch
with adriaan already, but bonus review by moors.
|
| |
|
|
|
|
|
| |
When TypeVars were given higher-order abilities, so too should have been
WildcardType, which acts as a plceholder for typevars. Always inflicting
arguments upon it was the cause of #2308. Closes #2308, review by moors.
|
| |
|
|
|
|
|
|
| |
Fixed an issue with higher kinded type inference on constructors without
any help from adriaan. Provisionally notched belt. Wrapped up as many
tickets as I added characters of code. Closes SI-3343, SI-4018. Review
by moors.
|
| |
|
|
|
|
|
|
|
|
|
| |
closes #4692: unification in type constructor inference now widens *and*
dealiases when necessary
in 2.8.1 implicit conversion search started with a widened type, so that
combo never came up
no review
|
| |
|
|
|
|
|
|
| |
Update manually created tree which was calling Predef.error to call
scala.sys.error instead. Created convenience functions in Definitions
for getting package objects akin to those for getting classes and
objects. No review.
|
| |
|
|
|
| |
review by rompf -- odersky may want to take a quick look and update the spec
|
| |
|
|
|
|
|
| |
Test case for implicits which unwrap typeclasses, something which must
really live on the edge given the multiple ways we've busted it lately.
Also some Array/signature and repl tests. No review.
|
| |
|
|
|
|
| |
Don't issue unchecked warnings on higher-kinded types. Closes #1439,
review by moors.
|
| |
|
|
|
|
|
| |
Compilation of spec-List enters an infinite loop under -optimise,
disabling in the hopes of seeing a new build before I die. I'll put it
back. No review.
|
| |
|
|
|
|
| |
Carved out access exception for java protected statics, which otherwise
cannot be accessed from scala. Changes close status of #1806, no review.
|
| |
|
|
|
|
|
|
| |
There were two distinct bugs in here, which if I ran the world would be
a wakeup call that robust software cannot emerge from thousands of lines
of low-level AST matching. In case you are frozen in suspense: I do not
run the world. Review by moors.
|
| |
|
|
|
| |
Finished reverting the misbegotten r23262, no review.
|
| |
|
|
|
|
|
| |
Fix for failing { val x = classOf[List[_]] } introduced by paulp
in r23262. I already had this in mind (see comments of #4419) but I was
holding back in the runup to 2.9. Closes #4419, review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Removes SUnit (long deprecated!) from the standard library.
the relatively small number of partest tests in Scala's suite that
were still using SUnit now either just use regular asserts, or they
print stuff that partest checks with a .check file. Also fixed some bad
indentation, removed ancient useless-looking commented-out code, etc.
Contributed by Seth Tisue (way to go seth) no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Suppress unwanted noise generated by javac when compiling test case for
#1263.
formerly the test case caused this to be printed:
Note: test/files/pos/t1263/Test.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
we suppress this using @SuppressWarnings.
Contributed by Seth Tisue, no review.
|
| | |
|
| |
|
|
|
|
|
| |
Finally figured out what was going on with a certain class of
exhaustiveness checking bugs. Hey moors, you can put away your pins,
puppets, and magic sauces. Closes #3098, no review.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Working my way through pattern matcher sequence issues mostly caused by
the special handling of Lists. Also deleting all kinds of useless or
almost useless code which is presently only clutter.
Closes #2756, #2800, #3050, #3530, #3972, no review.
|
| |
|
|
|
|
| |
Strip unused pattern variable bindings out before performing match
translation. Closes #4269, no review.
|
| | |
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Test cases for #1071 and #4275 since I don't see a lot of test cases,
hint hint, no review.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Looks like another java5/java6 difference gets me on a test. At least
this time I was looking for that. No review.
|
| |
|
|
|
|
| |
Expanding the test which tries to use the collections from java. No
review.
|
| |
|
|
|
| |
Looks like I accidentally committed a test log, no review.
|
| |
|
|
|
|
| |
Restoring my higher-kinded-Array signature check which martin callously
blew away while fixing all our other problems. Review by odersky.
|
