| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Added *.log and build/ to gitignore so partest/ant artifacts don't show
up in our commit messages. Also fixed whitespace issues arising from the
filter-branch history rewrite for git move.
|
| |
|
|
|
|
|
| |
Fixed type unsoundness problem in t5120 and also discovered by
roman.kalukiewicz@gmail.com. Fix should be refined further, as I am not
convinced we are quite done yet. Review by moors.
|
| | |
|
| |
|
|
|
| |
Guess that was a bad choice of class. No review.
|
| |
|
|
|
|
| |
Discovered an overloaded method with multiple unimplemented variants
only had one listed. Fixed, no review.
|
| | |
|
| |
|
|
|
|
| |
It's hidden behind -Xlint and pretty specific, but makes me feel better
anyway. References SI-4762, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A digression into motivations:
It's not there yet but the future looks bright. I have winnowed the
number of mutation points down and I will take it down much further.
There are only a few fundamental state changes which take place and
these can be made to happen in a systematic fashion at well-known
junctions.
1) Fresh symbols are allocated and (usually) assigned to a tree. 2)
Symbol flags and access are manipulated. 3) A (possibly lazy) info is
assigned to a symbol. 4) Synthetics are created or lazily positioned
for creation
Among the complications is that the symbol's info often cannot be
determined in a straightforward fashion lest cycles develop. Type
inference is obviously dependent on having some type information, so the
black art is to pursue a) only the right information and b) only as far
as necessary to avoid cycles.
Compounding the difficulty is that synthetic methods must be introduced
before the typer phase. Over time a variety of ad-hoc mechanisms have
evolved to deal with these difficulties, and they have gotten us a good
distance (we have bean setter/getters, case classes, copy methods,
default getters, and more) but there are big disadvantages:
- they are heavily custom fitted to the specific uses
- because of the intertwingling of namer and typer, it is all
only possible from the inside. Compiler plugins are shut out.
A particularly difficult scenario has recently arisen with case classes.
They now receive a ProductN parent, but because a class's parents must
be completed before it can be completed, we encounter this:
object Foo { type T = String }
case class Foo(x: Foo.T, y: Foo.T) { }
Now one of class Foo's parents is Product2[T, T]. So class Foo cannot be
completed without information from object Foo. But object Foo needs to
be given these synthetic methods:
def apply(x: T, y: T): Foo
def unapply(x: Foo): Option[(T, T)]
You can see these two have their hands all over one another.
The good news is that I have established in principle that the problem
can be overcome, for that use and I think in a sufficiently general way
that plugins will be able to perform this kind of method synthesis,
with the following approach. For synthetic methods which require type
information before they can be created (this is the catch-22: once type
information is available, it's too late to add new synthetic methods) we
create a "stub symbol" like so:
val sym = owner.newMethod("nameOfMethod")
sym setInfo stubMethodInfo
stubMethodInfo will be some very general method type like Any* => Any
(or Nothing => Any, it really depends on how or whether it is used),
whatever it takes to pass type checking. At the same time, we enter the
stub symbol into a map along with a thunk which creates the symbol and
tree the way we would if we had full type information.
Then, immediately after a class is typed, the template is examined for
stub method symbols and when found, they are updated with the symbol
info found in the map, assigned to the associated tree, and added to the
class template. This approach will probably break down under some uses,
but I think it can take us a long way.
So all these changes in Namers are about evolving it to a point where I
can roll out a principled division of responsibility for those entities
which cannot be naively typed, and to unify the several different
approaches to lazy typing under a consistent and predictable mechanism.
If anyone would like to review this, please be my guest, but you might
want to wait one more commit.
|
| |
|
|
|
|
|
|
|
|
| |
for now, left the old if(settings.YdepMethTpes.value) guards in comments
removed *.flags containing -Ydependent-method-types also updated one
check file with one fewer error
no review
|
| |
|
|
|
|
| |
Notice when a typeref's info creates an obvious cycle, so we can see an
error instead of a stack overflow. Closes SI-5093, review by moors.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
true == new java.lang.Boolean(true) will in fact sometimes be true. Also
fixes a bug caused by this change in r23627.
- lazy val SerializableClass = getClass(sn.Serializable)
+ lazy val SerializableClass = getClass("scala.Serializable")
It used to be java.io.Serializable. Hey, let's not change the meaning of
existing symbols which are in active use. No review.
|
| |
|
|
|
| |
Closes SI-5078, no review.
|
| |
|
|
|
|
|
|
|
| |
Pulling back from expensive path normalization caused a regression where
companions were no longer recognized as such after specialization.
(Specifically, the paths turned up as "test.scala" and "./test.scala".)
I made it a two-level check, doing the expensive one before failing.
Closes SI-5023, no review.
|
| |
|
|
|
|
|
|
| |
When many methods are missing, print a list of signatures the way they
need to be implemented, and throw in ??? stub implementations so it
should be compilable code. If anyone would like this logic exposed more
generally (for the IDE or whatever) just let me know. No review.
|
| |
|
|
|
|
|
|
|
|
|
| |
(T*)U now eta-expands to Seq[T] => U, not T* => U. There is a transition
command line switch to get the old behavior for any who may have relied
upon it:
-Yeta-expand-keeps-star
Closes SI-4176, no review.
|
| |
|
|
|
|
| |
One's devotion to aesthetics must not be allowed to trump one's
commitment to clearly delineated tuplehood. Closes SI-5067, no review.
|
| |
|
|
|
| |
See SI-5060. Review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Important note for busy commit log skimmers ***
Symbol method "fullName" has been trying to serve the dual role of "how
to print a symbol" and "how to find a class file." It cannot serve both
these roles simultaneously, primarily because of package objects but
other little things as well. Since in the majority of situations we want
the one which corresponds to the idealized scala world, not the grubby
bytecode, I went with that for fullName. When you require the path to a
class (e.g. you are calling Class.forName) you should use javaClassName.
package foo { package object bar { class Bippy } }
If sym is Bippy's symbol, then
sym.fullName == foo.bar.Bippy
sym.javaClassName == foo.bar.package.Bippy
*** End important note ***
There are many situations where we (until now) forewent revealing
everything we knew about a type mismatch. For instance, this isn't very
helpful of scalac (at least in those more common cases where you didn't
define type X on the previous repl line.)
scala> type X = Int
defined type alias X
scala> def f(x: X): Byte = x
<console>:8: error: type mismatch;
found : X
required: Byte
def f(x: X): Byte = x
^
Now it says:
found : X
(which expands to) Int
required: Byte
def f(x: X): Byte = x
^
In addition I rearchitected a number of methods involving:
- finding a symbol's owner
- calculating a symbol's name
- determining whether to print a prefix
No review.
|
| |
|
|
|
|
|
|
|
| |
It's nice when you can delete such absurd complication by figuring out
how to avoid it in the first place.
Also includes some Namer cleanup as I tried to follow the logic involved
to fix a protected[this] accessor bug. No review.
|
| |
|
|
|
| |
Closes SI-4319, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current design of error trees complicates the design of reflection
library, and introduces sometimes unnecessary boilerplate and since I
do not want to stall that work I am reverting all the changes related
to error trees. A different design is currently under consideration but
work will be done on separate branch on github.
Revisions that got reverted:
r25705, r25704 (partially), r25673, r25669, r25649, r25644, r25621, r25620, r25619
Review by odersky and extempore.
|
| |
|
|
|
|
|
| |
It was time. Removed unused flags and devirtualize detritus. Cleaned up
flags a bit further. Fixed the contents of phaseNewFlags in those places
where it was inaccurate. No review.
|
| |
|
|
|
| |
Review by Dragos.
|
| |
|
|
|
|
| |
Figured out how to turn it on by default, even.
Closes SI-4979, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various and sundry manipulations to allow for objects to be overridden
when the mood is right. It is not enabled by default.
The major contributor of change turned out to be the decoupling of
the FINAL flag (and the "isFinal" test which examines only that flag)
and the many semantics which were attributed to this interpretation
of finality in different circumstances. Since objects no longer have
the FINAL flag automatically applied (only top-level objects and those
marked final in source code do) we need apply a more nuanced test.
Fortunately there is such a nuanced test: isEffectivelyFinal,
which is always true if the FINAL flag is set but also in various
other circumstances. In almost every case, you should be testing
"isEffectivelyFinal", not "isFinal".
To enable overridable objects, use:
-Yoverride-objects
-Xexperimental // includes the above and others
Remain to be done: working out transition logistics. Most likely this
would involve bumping the scala signature version, and all objects in
versions before that would be assumed final.
Review by moors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are no more direct calls to context.error from Typers and Infer,
so more work needs to be done to finish it for Implicits and Namers.
I am pushing it to trunk so that all of you can share my pain (and
complain). Please do not add any more context.error randomly in that
code, instead deal with it appropriately (by creating specific error
tree).
I was trying to be as informative when it comes to error tree names
as possible, but if you feel like changing names to something more
appropriate then feel free to do so. When it comes to printing error
messages I tried to follow test suite as closily as possible but
obviously there were few changes to some tests (mostly positive, I
believe).
On my machine performance drawback was neglible but I am working on more
aggressive caching to reduce the penalty of containsError() calls even
more. Any suggestions welcome.
At the moment the code supports both styles i.e. throwing type errors
for the cases that are not yet handled and generating error trees. But
in the future we will drop the former completely (apart from cyclic
errors which can pop up almost everywhere).
Review by odersky, extempore and anyone who feels like it.
|
| |
|
|
|
|
|
|
| |
Offer warning when demonstrably non-side-effecting expressions appear in
statement position, which should be unintentional by definition. Threw
in removal of six places with useless discarded expressions which the
warning informed me about. No review.
|
| | |
|
| |
|
|
|
|
| |
Improved the error message given when a concrete method implementation
doesn't match the abstract one. No review.
|
| |
|
|
|
|
|
| |
Removing the code which has been deprecated since 2.8.0. Contributed by
Simon Ochsenreither, although deleting code is such fun one hesitates to
call it a contribution. Still, we will. Closes SI-4860, no review.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
