| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Move now-passing SI-963 test into neg.
Test for partial specialization.
Pending test for SI-5008.
Pending test for SI-4649.
Abstract array type test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- TypeTestTreeMaker subsumes the old TypeTestTM and TypeAndEqualityTM
its type- and equality-testing logic is configurable so that it can:
- generate trees (main purpose)
- check whether this tree maker is a pure type test
- generate the proposition that models this tree maker
(for exhaustivity and other analyses)
- [CSE] subst binders of dropped tm's to stored ones
somehow the refactoring broke the replacement of the binder of dropped
treemakers by the binder of the reused treemaker
when replacing
TM1(x1 => ...) >> TM2(x2 => ...) >> TM3(x3 => ...) >> ...
TM1'(x1' => ...) >> TM2'(x2' => ...) >> TM3(x3' => ...) >> ...
by
Memo1(x1 => ...) >> TM2(x2 => ...) >> Memo2(x3 => ...) >> ...
Reuse(Memo2)...
you need to replace x1' and x2' by x1
since TM2 tested a shared condition but was not memo-ised,
that implies it simply passed x1 through to x3 unmodified,
and x2' can simply use the stored x1
- type of first uniqued binder sets type of tree
when approximating a tree of treemakers as a DAG,
where sharing indicates the same value is tested,
use the type of the binder that was first used to
create a unique tree as the type of that tree,
and thus all trees used for the same binder in the future
- track substitution of alternatives when approximating
- error on unswitchable @switch annotated matches
if we can't turn a match (with more than two cases) into a switch,
but the user insists, emit an error
misc notes:
- when all you need is nextBinder, FunTreeMaker is your guy
- must pass flag to TypeTestTM for extractorarg test
case TypeTestTreeMaker(prevBinder, testedBinder, expectedTp, nextBinderTp)
(prevBinder eq testedBinder) does not imply it's a pure type test for an extractor call
note that the expected type for an extractor argument is not a type pattern,
thus we only do a classic type test -- the idea was to detect that case by noticing we're
being called with the same previous and tested binder, but that case also arises
for Typed patterns
|
| |
|
|
|
|
|
|
| |
Closes SI-4482, SI-4651, SI-3702.
Pending tests for SI-1832, SI-3439, SI-5091, SI-5231, SI-5265.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you can't get your hands on something which crashes
scalac - I know, I know - you can try this ready-made crasher.
% cat test/pending/pos/t4717.scala
trait Bounds[@specialized A] {
// okay without `>: A`
def x[B >: A]: Unit = new Bounds[B] {
lazy val it = ??? // def or val okay
it
}
}
% scalac -d /tmp test/pending/pos/t4717.scala
error:
while compiling: test/pending/pos/t4717.scala
during phase: specialize
library version: version 2.10.0-20120510-134429-ce1d68ed19
compiler version: version 2.10.0-20120510-152646-ba4dfd1e63
reconstructed args: -d /tmp
last tree to typer: Select(This(trait Bounds$mcZ$sp), x$mcZ$sp)
symbol: method x$mcZ$sp in trait Bounds$mcZ$sp (flags: override <method> <specialized>)
symbol definition: override def x$mcZ$sp[B >: Boolean](): Unit
tpe: [B >: Boolean]()Unit
symbol owners: method x$mcZ$sp -> trait Bounds$mcZ$sp -> package <empty>
context owners: value it -> anonymous class $anon -> method x$mcZ$sp -> trait Bounds$mcZ$sp -> package <empty>
== Enclosing template or block ==
Block(
Assign(
$anon.this."it "
Apply( // def ???(): Nothing in object Predef, tree.tpe=Nothing
scala.this."Predef"."$qmark$qmark$qmark" // def ???(): Nothing in object Predef, tree.tpe=()Nothing
Nil
)
)
$anon.this."it " // lazy private[this] var it: Nothing, tree.tpe=Nothing
)
== Expanded type of tree ==
PolyType(
typeParams = List(TypeParam(B >: Boolean))
resultType = NullaryMethodType(
resultType = TypeRef(TypeSymbol(final class Unit extends AnyVal))
)
)
// And then the usual stack trace
|
|
|
|
| |
Closes SI-5210.
|
| |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
'scalamacros/ticket/5726', 'scalamacros/ticket/5610', 'scalamacros/ticket/5654', 'scalamacros/ticket/5521', 'scalamacros/ticket/5585', 'scalamacros/ticket/5503', 'scalamacros/ticket/4728', 'scalamacros/ticket/5534' and 'scalamacros/ticket/4560'
|
| | |_|_|_|/
| |/| | | | |
|
| | |_|_|/
| |/| | | |
|
| | |_|/
| |/| | |
|
| | |/
| |/| |
|
| |/ |
|
| | | |
| \ | |
| \ | |
| \ | |
|\ \ \|
| | | |
| | | |
| | | | |
'refs/pull/488/head'; commit 'refs/pull/489/head'; commit 'refs/pull/490/head' into develop
|
| |/ / |
|
|/ / |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
| |
Most are pattern matcher bugs fixed by virtpatmat. A few are reifier,
package object, or miscellaneous. I threw in an original test for
SI-2337, to go with those for SI-1697, SI-3705, SI-4415, and SI-1357,
all of which (in the interests of making sure this basket has all the
eggs) I am closing.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
* all usages of ClassManifest and Manifest are replaced with tags
* all manifest tests are replaced with tag tests
|
| |
|
|
|
|
|
|
| |
Remove obsolete, move passing pending -> files, update
those-kinds-are-high with some new info, added a couple
new ones to pending.
|
|
|
|
|
|
| |
And some tests for pending.
Closes SI-5358.
|
|
|
|
| |
Some in pending, some in files. Closes SI-4770.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The crickets at http://www.scala-lang.org/node/11901 were in
unanimous agreement that I should proceed as suggested.
- No arguments to @specialize gets you 10/10, not 9/10
- Fixed bugs in AnyRef specialization revealed by trying to use it
- Specialized Function1 on AnyRef.
- Changed AnyRef specialization to use OBJECT_TAG, not TVAR_TAG.
- Deprecated SpecializableCompanion in favor of Specializable,
which has the virtue of being public so it can be referenced
from outside the library.
- Cooked up mechanism to group specializable types so we don't
have to repeat ourselves quite so much, and create a few groups
for illustrative purposes. I'm not too serious about those names
but I used up all my name-thinking-up brain for the day.
- Updated genprod and friends since I had to regenerate Function1.
- Put tests for a bunch of remaining specialization bugs in pending.
Closes SI-4740, SI-4770, SI-5267.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a window of danger when multiple related elements are
being typed where something which is conceptually one thing can
slip into two things, and those two things can be incompatible
with one another. Less mysteriously, c478eb770d fixed this:
def f = { object Bob ; Bob } ; val g = f
But, it did not fix this:
def f = { case class Bob() ; Bob } ; val g = f
See test case pos/existentials-harmful.scala for an "in the wild"
code example fixed by this commit.
The root of the problem was that the getter and the field would each
independently derive the same existential type to describe Bob, but
those existentials were not the same as one another.
This has been the most elusive bug I have ever fixed. I want to cry when
I think of how much time I've put into it over the past half decade or
so. Unfortunately the way the repl works it is particularly good at
eliciting those grotesque found/required error messages and so I was
never able to let the thing go.
There is still a cosmetic issue (from the last commit really) where
compound types wind up with repeated parents.
Closes SI-1195, SI-1201.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Don't want to chase NPEs around for the rest of my life. Created
"NoCompilationUnit" and "NoSourceFile" objects to represent not-present
versions of these items. Seems a lot better than null. References
SI-4859, got past NPE only to uncover the actual problem. No review.
|
|
|
|
|
| |
A few tests for pending and non-pending, no review.
|
|
|
|
|
|
| |
Bounded wildcard types arising during pattern type inference can cause
unnecessary crashes. Closes #1048, 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.
|
| |
|
|
|
|
|
| |
Finished reverting the misbegotten r23262, no review.
|
| |
|
|
|
|
|
|
|
| |
One last batch of test cleanups and I think I'll call it a day. If
you're worried I didn't leave any for anyone else, let me put your fears
to rest. PLENTY left to sift through. No review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Moved the test for #3420 to pending and reopened the ticket. The bug
only materializes if scalac was itself built with -optimise. (We may
need a richer language for describing optimise bugs.) No review.
|
|
|
|
|
|
|
|
| |
changes necessary to plug it back in while preserving everything which
has happened since then in tests and such, but we should be the lookout
for overreversion. Review by phaller (but as a formality, I don't think
it requires direct review.)
|
|
|
|
|
|
|
|
|
| |
As a brief diversion from real work, implemented Damerau–Levenshtein
and ran it on trunk to elicit obvious misspellings. Unfortunately
they're mostly in places like compiler comments which real people never
see, but I fixed them anyway. All those English Lit majors who peruse
our sources are sure to be pleased. No review.
|