| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The eagerly awaited companion commit to r23622, the surprise hit of last
winter. Singletons now have the singleton type inferred in monomorphic
contexts as well. In english:
scala> object X
defined module X
scala> def f = X
f: X.type
Wait, that's not english. English review by moors.
|
| |
|
|
|
|
|
|
| |
Fixed a crasher in the scanner when unicode escape sequences offered up
EOF before completion. Also made the repl a little more robust against
crashers in scalac. Treat it like a hostile witness! Closes #4584, 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.
|
| |
|
|
|
| |
Reverts a change as a tribute to the performance gods, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
do I import" code to notice _root_.scala.Predef too. Moved some of the
overly specialized, called-only-once functions in treeInfo inside the
one function which needs them. References #1931. No review.
|
| |
|
|
|
| |
No review.
|
| |
|
|
|
|
| |
Tightened a condition to avoid a self-referential pattern variable
crash. Closes #3392, 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.
|
| |
|
|
|
|
| |
A better test case for #4537 than the one r24881 didn't include, no
review.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Since I don't want to commit anything "interesting" until we ship 2.9, a
few uninteresting cleanups involving how types are printed, getting some
debugging code in shape to prepare for the long winter ahead, etc. No
review.
|
| |
|
|
|
|
|
|
| |
Completely to my surprise, found that fixing all those sequence issues
revealed that the pattern matcher can catch a lot more inexhaustive
cases than it has been catching. Fixed most of the inexhaustive matches
in the compiler, which had become a bit warnier. No review.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wrote a warning when nullary methods return Unit. I wimped out of
including it in this patch because we had about 200 of them, and that's
what is fixed in this patch. I will add the warning to some kind of
"-Xlint" feature after 2.9.
This is motivated at least partly by the resolution of #4506, which
indicates the distinction between "def foo()" and "def foo" will
continue to jab its pointy stick into our eyes, so I believe we have a
minimal duty of at least following our own advice about what they mean
and not making a semirandom choice as to whether a method has parens or
not. Review by community.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improved the error message for another of the most common situations
I hear about in newbieland. It could be taken further. If compilation
fails due to an unimplemented abstract method, and there is a concrete
method of the same name and arity, it will do a pairwise analysis of the
parameters and attempt to further explain where you went off the beam if
it feels it can do so sensibly. Such as in the test case:
% scalac S.scala
S.scala:1: error: class S needs to be abstract, since method g in class J of type (y: Int,z: java.util.List)Int is not defined
(Note that java.util.List does not match java.util.List[String]. To implement a raw type, use java.util.List[_])
class S extends J {
^
one error found
No review.
|
| |
|
|
|
|
| |
Added warning when someone tries to return a non-Unit value from a Unit
method, no review.
|
| |
|
|
|
|
| |
Removed restriction on case classes having only two parameter lists.
Closes #1333, 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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Modified some typer logic to allow annotation arguments for constants
which don't have the form Literal(_). The current logic seems to be
avoided most of the time, but scaladoc breaks when it runs into it. This
closes #4301. I can't figure out from the ticket what the deal is with
#2764 and what is presently happening, but it seems like this patch
could only improve the situation. Review by rytz.
|
| |
|
|
|
|
|
| |
Added some implicitNotFound annotations to commonly used classes, and
some documentation to Manifest. (Said documentation is invisible for the
moment due to #4404.) No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[I'm laptop only so there's some chance this will incur temporary
breakage, but it needs committing.]
Heading off gratuitous complications which haven't yet shipped, I
eliminated the -jar startup option in favor of doing what we already do,
figuring it out. So now all these things work.
scala foo/bar.scala // if file is a script or has one main method
scala foo.Bar // if it has a legal main method scala foo.jar // if it
has a legal MainClass attribute
Also changed "-savecompiled" to "-save" and given scala source called
foo.scala, generate foo.jar rather than foo.scala.jar. Cleaned up a
bunch of related code and further polished the scala startup message.
And unbroke choice settings and improved that error too, which closes
#3849.
While trying to write a test for the choice setting, was reminded that
partest just discards invalid flags files. Made it fail instead, which
closes #3712. Fixed the new failures that revealed. No review.
|
| |
|
|
|
| |
no review.
|
| |
|
|
|
|
|
|
|
|
|
| |
warnings due to my changing a map from mutable to immutable (which
ought to be the good direction) because "def update" still lingers on
immutable maps. I counted the days elapsed since it was marked for death
(before 2.8.0) and added in the bugliness of what I was looking at and
bid it farewell.
Now removed: def update on immutable maps. No review.
|
| |
|
|
|
| |
Slight tweak to case class deprecation message, no review.
|
| |
|
|
|
|
|
|
|
|
|
| |
Addresses the issues swirling around Double.Epsilon and friends which
were battled out in more than one venue and then aptly summarized by
retronym in #3791. Thanks to Simon Ochsenreither for submitting a patch;
I wasn't able to use too much of it because the source code for these
types is generated, but effort is always appreciated. Closes #3791, and
I'm tired and I'd hate to blow this one at this late date: review by
rytz.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Raised the scariness of the case class deprecation message. (I hope
you don't mind, hubert, I like writing scary messages.) Closes #4109 I
suppose, no review.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another lap around the track with generic signatures. At the root of the
issue reported in #4214 is our old friend (fondly remembered from the
days of primitive equality) boxed/primitive unification.
// scala
trait T[A] {
def f(): A
}
// the generic signature spec doesn't allow for parameterizing
// on primitive types, so this cannot remain Char. However
// translating it to Character, as was done, also has issues.
class C extends T[Char] {
def f(): Char = 'a'
}
// Note that neither of the signatures for f, the implementation // or
the bridge method, matches the type parameter. Generic interfaces in
class: T<java.lang.Character> Generic signatures: public char C.f()
public java.lang.Object C.f()
After this commit, primitive type parameters are translated into Object
instead of the boxed type. It was martin's idea, so no review. Closes
#4214.
|
| | |
|
| |
|
|
|
|
|
|
| |
Observed that some historical issues with package objects no longer seem
so issuey. In the interests of keeping the arbitrary limitations to a
minimum, re-enabled case classes in package objects (see #2130, #3437.)
Closes #3437, review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the frequency with which I hear questions about it and similar,
this error message assumes too much understanding.
scala> scala.collection.mutable.MultiMap(1, 2, 3) <console>:8: error:
value MultiMap is not a member of package scala.collection.mutable
Now it says:
scala> scala.collection.mutable.MultiMap(1, 2, 3) <console>:8: error:
object MultiMap is not a member of package scala.collection.mutable
Note: trait MultiMap exists, but it has no companion object.
No review.
|
| | |
|
| |
|
|
|
|
| |
Improved an error message involving overload+default args. Closes #3909,
no review.
|
| |
|
|
|
|
| |
Some cleanup from investigating #4041, with a comment instead of a fix
for the ticket. Review by rytz in case he sees a good way to fix it.
|
| |
|
|
|
|
| |
Fix for parser regression allowing 0-case match blocks. Closes #4217, no
review.
|
| |
|
|
|
|
| |
A raw tree was making its way into an error message. Removed. Closes
#4196, no review.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
closes #2741, #4079: pickling now ensures that a local type param with
a non-local owner, which will thus get a localized owner, will only get
a class as its localized owner if its old owner was a class (otherwise,
NoSymbol) this ensures that asSeenFrom does not treat typerefs to this
symbol differently after pickling.
todo: should we pro-actively set the owner of these type params to
something else than the type alias that they originate from? see notes
in typeFunAnon
review by odersky
|
| |
|
|
|
|
| |
review by extempore
(because of recent sin against this holy principle)
|
