| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AnyVal types become source files instead of polite compiler
fictions.
!! You'll need a serious "ant all.clean" now. !!
As of this commit the system is fully bootstrapped and the
synthetic code eliminated: only the source files remain. The
sort-of-AnyVal-companions in scala.runtime.* have all been eliminated
because the actual companions can do everything; deprecated vals in
the scala.runtime package object point to the companions. This left
AnyValCompanion as the only AnyVal related thing in the runtime package:
that made little sense, so I deprecated and moved it as well.
Starr is based on r24066 plus this commit. Closes #4121. Review by rytz,
odersky.
|
| |
|
|
|
|
| |
Defer a check from the typer to refcheck so the error message makes some
sense. Closes #4174, review by rytz.
|
| |
|
|
|
|
| |
Look even harder for attempts to sneak "this" into superconstructor
arguments, and improve positioning. Closes #4166, no review.
|
| | |
|
| |
|
|
|
|
|
| |
What is, I think, the only possible solution to bug #4158 given the
current ways of controlling implicits. Let's just be glad there's one
instead of zero. Closes #4158, review by moors.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This outlaws explicit isInstanceOf tests on value types, which are
nonsense in any case, as long threatened in ticket #1872. Closes #1872,
review by rytz.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imported sbt.Process into trunk, in the guise of package
scala.sys.process. It is largely indistinguishable from the version in
sbt, at least from the outside.
Also, I renamed package system to sys. I wanted to do that from the
beginning and the desire has only grown since then. Sometimes a short
identifier is just critical to usability: with a function like error("")
called from hundreds of places, the difference between system.error and
sys.error is too big. sys.error and sys.exit have good vibes (at least
as good as the vibes can be for functions which error and exit.)
Note: this is just the first cut. I need to check this in to finish
fixing partest. I will be going over it with a comb and writing
documentation which will leave you enchanted, as well as removing other
bits which are now redundant or inferior. No review.
|
| |
|
|
|
|
|
|
|
| |
I had closed #2441 as a duplicate of that, but unfortunately #4114 did
not bring #2441 along with it. Then I realized I'm a programmer, not a
helpless trac watcher. As is often the case with thes things, fixing
that revealed a bug in the library. Closes #2441 for real, review by
odersky.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A pretty severe bug in the recognition of tail call elimination.
It turns out that Tailcalls will perform "partial elimination" in
situations such as:
@annotation.tailrec final def f(x: Int): Int = f(f(x))
The outer call to f1 becomes a jump, but the inner call remains as
it was. I implemented @tailrec under the impression that if the
optimization had taken place, it had gone all the way. So this is now
fixed with a direct examination of the rewritten tree.
While I was in there I threw in some improved error reporting: the error
positioning is now on the call which is not in tail position rather than
the method declaration.
Closes #4135, no review.
|
| |
|
|
|
|
|
|
|
|
|
| |
scala> implicitly[CanBuildFrom[String, Int, List[List[Int]]]]
<console>:10: error: Cannot construct a collection of type
List[List[Int]] with elements of type Int based on a collection of type
List[List[Int]]. implicitly[CanBuildFrom[String, Int, List[List[Int]]]]
^
No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently my flailing attempts to make things faster earned me the
pity of Tiark, who sent this monster patch which he probably dashed
off before the appetizers had been cleared away. All the steak is his
but I threw in a little sizzle so I could feel like a part of things.
It knocks about a bazillion miniseconds off the time spent in implicit
search.
This is the same patch martin already endorsed, give or take several
hundred lines of diff, so I will say no review, even though I know it
will be hard to look away. I trimmed most of the "speculative code"
(that is, the commented out bits) because it's getting awfully busy
along those sidelines. I will preserve the ideas in some more structured
form.
|
