| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|