| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Expanded the range of a warning, and made suppressed warnings visible.
Modified the positioning of "permanently hidden" errors so that when
there is more than one, the later ones are not ignored. Also changed the
error suppression code to emit the error anyway if -Ydebug was given (it
is prefixed with "[suppressed] ".) Since I can't be the only one who
wondered where his errors were vanishing to. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reversed the values of "is" and "is not" in recent for comprehension
deprecation.
DO NOT BLOW HATCH
REPEAT
DO NOT BLOW HATCH
"Roger! Hatch blown."
Events reveal it was all baby, no bathwater. It turns out that the
specification is merely a document, not infallible holy writ as we
had all previously believed. So it is not the ABSENCE of val in a for
comprehension assignment which is deprecated, it is the PRESENCE of val.
Summarizing again, more accurately perhaps:
for (x <- 1 to 5 ; y = x) yield x+y // THAT's the one
for (val x <- 1 to 5 ; y = x) yield x+y // fail
for (val x <- 1 to 5 ; val y = x) yield x+y // fail
for (x <- 1 to 5 ; val y = x) yield x+y // deprecated
No review.
|
| |
|
|
|
| |
update on this matter is yet to come, no review.
|
| |
|
|
|
|
|
| |
Fixing all the tests and source which still use the old for
comprehension syntax with vals where there are no vals and no vals where
there are vals. No review.
|
| |
|
|
|
|
| |
Better error message for case class/object match confusion. Closes
SI-4879, no review.
|
| |
|
|
|
|
| |
Avoid some spurious errors after a cyclical reference error. Closes
SI-2388, no review.
|
| |
|
|
|
|
| |
Improved structural type error messages, and other error message related
boosts. Closes SI-4877, review by odersky.
|
| |
|
|
|
|
|
| |
Disallowed implicit modifier on auxiliary constructors, since it either
silently accomplishes nothing or crashes the compiler. If it should do
something useful let me know. Closes SI-4882, review by odersky.
|
| |
|
|
|
| |
Issue a warning about classes/objects inside package objects, no review.
|
| |
|
|
|
|
|
|
| |
Cleanups in Namers and AddInterfaces emerging from bugfixing attempts
and comprehension pursuits. I appear to have accidentally fixed at least
one bug, as there are new (correct) warnings when building the compiler
involving permanently hidden imports. No review.
|
| |
|
|
|
|
| |
Made error messages like "object List is not a value" be a little more
helpful about why that is. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
output generation (but only then, since otherwise we're not creating the
jar):
1) -Xmain-class foo.Bar will give the jar a Main-Class of foo.Bar 2)
Alternatively, if there is only one runnable program, that will be
the Main-Class 3) Always, the jar's manifest will have an entry for
Scala-Compiler-Version.
Not very relatedly, a warning is now issued when a module has a main
method but a runnable program will not be generated. Closes SI-4861.
This represents an opening step toward automatically recognizing
mismatched bytecode situations: coarse, but useful and safe. Review by
mirco.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Ywarn-adapted-args // also included in -Xlint
-Yno-adapted-args
The former warns when a () is inserted or an argument list is implicitly
tupled. The latter errors under the same conditions. Using these options
I found several bugs in the distribution which would otherwise be nearly
impossible to spot. These bugs were innocuous (I think) but similar bugs
could easily be (and have been) otherwise.
Certain particularly threatening scenarios are at minimum warned about
regardless of options given. Closes SI-4851, no review.
|
| |
|
|
|
|
|
| |
prohibit case-to-case inheritance instead of issuing warning. closes
#4109. review by extempore, since it should make your life much easier
in the pattern matcher
|
| |
|
|
|
|
| |
Don't enter into same line infinite recursion when erroneous code
involves a self-normalizing type alias. Closes #3240, review by moors.
|
| | |
|
| |
|
|
|
|
| |
Catch type projections even when they disguise themselves as stable via
singleton bounds. Closes #1431, review by odersky.
|
| |
|
|
|
|
| |
Suppressed an error in type constructor bounds checking which was
obscuring the meaningful error to follow. Review by moors.
|
| |
|
|
|
| |
meant for --grep to look in checkfiles too, and now it does. No review.
|
| |
|
|
|
|
| |
Having established that r25051 is not responsible for the compilation
issue with scalaz, it is hereby restored. Review by moors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Warning! Warning! Yes, that's what's in this commit. Why are you
panicking?
Mostly new command line options:
-Xlint // basically, the ones which aren't noisy Ywarn-all
-Ywarn-dead-code Ywarn-inaccessible // try this one on the library:
-it makes some good points Ywarn-nullary-override Ywarn-nullary-unit
-Ywarn-numeric-widen Ywarn-value-discard
Some accumulated motivations:
The wontfix resolution of ticket #4506 indicates that "def foo" and "def
foo()" are always going to be treated differently in some situations
and the same in others without users having any way to fix it. Summary
expressed in latest comment with which I agree (and quite sadly, given
that I've done a lot of work to try to make them usable) is "avoid using
structural types like the plague." But the least we can do is warn if
you're using parentheses "wrong".
I think it would be better if the warning about "def foo()" overriding
"def foo" were an error instead. If we have to live with this...
trait Me { def f(): Int }
class A { def f: Int = 5 }
class C extends A with Me { }
// error: Int does not take parameters
def f(x: C) = x.f()
// compiles
def f(x: Me) = x.f()
// error: Int does not take parameters. Mmph, how can a method be
// legal with parameter "Foo" and illegal with parameter "Foo with
// Bar" ?
def f(x: Me with C) = x.f()
The warning about a method contains a reference to a type which is less
accessible than the method itself is obviously to those who recall it
a response to GenTraversable being private and appearing in flatMap's
signature during the 2.9.0 RCs. It avoids warning in the case where the
unnormalized type is inaccessible but the normalized version would be,
but it could use further refinement.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Overrode contains and apply in mutable.HashMap to avoid allocating
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.
|
| |
|
|
|
| |
Moved test for #4727 to where it was supposed to go, no review.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Reverts r25051 due to witnessed movement of scalaz in the noncompiling
direction. Postmortem help I hope in the review by moors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Proliferating the number of debugging modes because it's still way
too hard to see what's going on in there. Until we get hubert's type
debugger with its whiz-bang whizbanginess, we'll have to struggle along
with somewhat prettier ascii. This introduces:
-Yinfer-debug
which tries to print in readable fashion what is happening in the
worlds of inference and implicit search. It should be made a bit more
complementary and less overlappy with -Ytyper-debug. No review.
|
| |
|
|
|
|
| |
Carved out access exception for java protected statics, which otherwise
cannot be accessed from scala. Changes close status of #1806, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
