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.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25149 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
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"
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25148 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
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.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25147 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
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.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25146 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
object. It's a blunt instrument: if people have lots of these conflicts
they need to resolve in individually nuanced fashion, they'll probably
remain out of luck. But now people can use YourKit probes without a
custom hacked compiler. Let's say this closes#2089. Review by odersky.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25145 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
attempt to solve mystery: explicitly set return type of Any#getClass()
to Class[_ <: Any] rather than allowing java's to be used. I'm
guessing that somehow it materializes as Class[_ <: Any] sometimes
and Class[_ <: AnyRef] other times. Review by moors.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25138 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
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.)
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25137 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
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.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25133 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
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.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25132 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
unnecessary intermediate data structures and multiple traversals of
lists. Also trying to get that code under control: it dwarfs all
other phases in terms of debugging output, and a too-large percentage of
the source is commented out debugging code which looks past its sell-by
date. I realize the patch is a little big for a very thorough review,
but review by dragos, prokopec.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25125 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
which apparently is making the IDE refuse to overwrite classfiles.
For the life of me I can't find why there should be any difference.
Bowing to expedience, no review.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25117 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
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.
git-svn-id: http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk@25110 5e8d7ff9-d8ef-0310-90f0-a4852d11357a
extempore