| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
Some work on error messages, somewhat based on ideas in #3092. No
review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some refinement of the error messages when the found and required types
have the same simple names. No longer must we watch people scratch their
heads at such messages as:
found : scala.collection.Set[String]
required: Set[String]
Now so clear you could enjoy a movie through it:
found : scala.collection.Set[String]
required: scala.collection.immutable.Set[String]
No review.
|
| |
|
|
|
|
|
|
|
|
|
| |
Determined that half a dozen ways of checking for varargs and
by-name-ness in param lists exceeded the legal limit. Also assessed that
names which are only used as type names would be a lot easier to deal
with if we created them as type names up front. Performed the changes
implied by the preceding along with a partial cleanup on TreeInfo which
one can see hasn't had a good look in a long time. (And still hasn't.)
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some uninteresting code related to error messages, which I'm checking
in mostly because I booted the r23379 commit in a git-svn meltdown and
posterity demands the message, which was:
You can now use the self-type of an anonymous class as a singleton type
in a pattern match ON THE MOON. Actual test case excerpt:
val x4 = new { self =>
def f(x: Any) = x match {
case _: x1.type => 1
case _: x2.type => 2
case _: x3.type => 3
case _: self.type => 4
case x: Dingus.type => x.IamDingus
}
}
Closes #576, 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
|
|
|
Created TypeDiagnostics trait and have begun opportunistically moving
code into it. Along the way, some improvements to error messages.
The situation described in ticket #2206 has always had an applicable
error message, but it wasn't making it out to the user. More kinds of
ambiguity are disambiguated, see the test cases. And overload errors are
printed with some formatting so one has some hope of parsing. Review by
odersky.
|
