| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
Fixed a bug involving classOf[Foo] having the wrong erasure. Luckily I
had only days ago deciphered the unique handling of classOf, so I knew
what was up. Closes #4753, review by odersky.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Somehow case objects fell through the cracks and have had default
hashCode implementations, leading to new hashCodes on each jvm run. Now
we use the productPrefix, and inline it right into the bytecode.
scala> None.## == "None".##
res0: Boolean = true
Closes #4752, no review.
|
| |
|
|
|
|
| |
Keep BufferedSource from losing buffered data when a derivative iterator
is created via getLines. Closes #4671, #4662, no review.
|
| | |
|
| |
|
|
|
|
| |
Having established that r25051 is not responsible for the compilation
issue with scalaz, it is hereby restored. Review by moors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Warning! Warning! Yes, that's what's in this commit. Why are you
panicking?
Mostly new command line options:
-Xlint // basically, the ones which aren't noisy Ywarn-all
-Ywarn-dead-code Ywarn-inaccessible // try this one on the library:
-it makes some good points Ywarn-nullary-override Ywarn-nullary-unit
-Ywarn-numeric-widen Ywarn-value-discard
Some accumulated motivations:
The wontfix resolution of ticket #4506 indicates that "def foo" and "def
foo()" are always going to be treated differently in some situations
and the same in others without users having any way to fix it. Summary
expressed in latest comment with which I agree (and quite sadly, given
that I've done a lot of work to try to make them usable) is "avoid using
structural types like the plague." But the least we can do is warn if
you're using parentheses "wrong".
I think it would be better if the warning about "def foo()" overriding
"def foo" were an error instead. If we have to live with this...
trait Me { def f(): Int }
class A { def f: Int = 5 }
class C extends A with Me { }
// error: Int does not take parameters
def f(x: C) = x.f()
// compiles
def f(x: Me) = x.f()
// error: Int does not take parameters. Mmph, how can a method be
// legal with parameter "Foo" and illegal with parameter "Foo with
// Bar" ?
def f(x: Me with C) = x.f()
The warning about a method contains a reference to a type which is less
accessible than the method itself is obviously to those who recall it
a response to GenTraversable being private and appearing in flatMap's
signature during the 2.9.0 RCs. It avoids warning in the case where the
unnormalized type is inaccessible but the normalized version would be,
but it could use further refinement.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hunch by adriaan (needed to change Object to Any in strategic location),
location + fix determined by paul,
menial work (reverts of obsolete spears and introduction of fix) by
adriaan
review by extempore
Revert "A line missed from spear thrust, no review. Revert "
"Thrusting spear into darkened alcove attempting to slay java5 "
Revert "New theory: fails running on java 1.5. Put in hack to "
discover Revert "Everything builds for me, but apparently not for "
jenkins. First "
|
| |
|
|
|
|
|
|
| |
Overrode contains and apply in mutable.HashMap to avoid allocating
an unnecessary Some on every call to either of them. Fruit looks a
little better defended in immutable.HashMap, so I deleted a bunch of old
debugging code instead. Closes #4469, no review.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
truth of theory. No review.
|
| |
|
|
|
| |
Moved test for #4727 to where it was supposed to go, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A total rewrite of "runtimeClass", discarding the user-space approach in
favor of simply fixing getClass.
def f1 = 5.getClass // Class[Int]
def f2 = (5: AnyVal).getClass // Class[_ <: AnyVal]
def f3 = (5: java.lang.Integer).getClass // Class[_ <: java.lang.Integer]
class A
class B extends A
def f1 = (new B: Any).getClass().newInstance() // Any
def f2 = (new B: AnyRef).getClass().newInstance() // AnyRef
def f3 = (new B: A).getClass().newInstance() // A
def f4 = (new B: B).getClass().newInstance() // B
But that's not all!
def f0[T >: B] = (new B: T).getClass().newInstance()
def f5 = f0[Any] // Any
def f6 = f0[AnyRef] // AnyRef
def f7 = f0[A] // A
def f8 = f0[B] // B
Closes #490, #896, #4696. Review by moors. (Note: I think this is pretty
good, but picky review requested.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Removed "isInterpreterWrapper" from the conditions which imply an
effective root. This was an old hack from before my time which is no
longer necessary and then recently became actively hostile. Closes
#4710, no review.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Routed Stream.+: through cons to avoid some truly pathological
performance. Closes #4697, no review.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
|
| |
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 overflow which occurs in hashtable size computations. Fixes
#4678.
No review.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
Go back to printing the message that transcript pastes can be finished
with ctrl-D. No review.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Views using methods implemented in terms of isEmpty (in particular,
headOption and lastOption) were traversing the collection twice up
to the nonEmpty element, because "if (isEmpty) None else Some(head)"
means calling isEmpty separately from head. I overrode those methods in
TraversableViewLike to avoid the second traversal.
This leaves at least init and tail still in that boat, but they were
getting too involved.
How do I say "review by pool of reviewers", who can help set that up? In
the meantime no review.
|
| |
|
|
|
|
| |
The '#' sign may easily to lead to problems, So we use '_' instead of
'#'. Closes #4641.
|
| |
|
|
|
|
| |
Don't issue unchecked warnings on higher-kinded types. Closes #1439,
review by moors.
|
| | |
|
