| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| | |
Quieting things down. Fixed some things revealed by quieter
logs, like forwarders being generated for superaccessors.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I guess these are self-explanatory.
@inline final def afterErasure[T](op: => T): T = afterPhase(currentRun.erasurePhase)(op)
@inline final def afterExplicitOuter[T](op: => T): T = afterPhase(currentRun.explicitouterPhase)(op)
...
@inline final def beforeTyper[T](op: => T): T = beforePhase(currentRun.typerPhase)(op)
@inline final def beforeUncurry[T](op: => T): T = beforePhase(currentRun.uncurryPhase)(op)
This commit is basically pure substitution. To get anywhere interesting
with all the phase-related bugs we have to determine why we use atPhase
and capture that reasoning directly. With the exception of erasure, most
phases don't have much meaning outside of the compiler. How can anyone
know why a block of code which says atPhase(explicitouter.prev) { ... }
needs to run there? Too much cargo cult, and it should stop. Every usage
of atPhase should be commented as to intention.
It's easy to find bugs like
atPhase(uncurryPhase.prev)
which was probably intended to run before uncurry, but actually runs
before whatever happens to be before uncurry - which, luckily enough, is
non-deterministic because the continuations plugin inserts phases
between refchecks and uncurry.
% scalac -Xplugin-disable:continuations -Xshow-phases
refchecks 7 reference/override checking, translate nested objects
uncurry 8 uncurry, translate function values to anonymous classes
% scalac -Xshow-phases
selectivecps 9
uncurry 10 uncurry, translate function values to anonymous classes
Expressions like atPhase(somePhase.prev) are never right or are at best
highly suboptimal, because most of the time you have no guarantees about
what phase precedes you. Anyway, I think most or all atPhases expressed
that way only wanted to run before somePhase, and because one can never
be too sure without searching for documentation whether "atPhase" means
before or after, people err on the side of caution and overshoot by a
phase. Unfortunately, this usually works. (I prefer bugs which never work.)
|
| | |
| |
| |
| |
| |
| | |
ClassDefs, CaseDefs, and LabelDefs. Dotting eyes,
crossing tees. Point of diminishing returns is reached,
declare victory and withdraw.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I guess I'd seen DefDef(mods, name, tparams, vparamss, tpt, rhs)
one too many times and went a little crazy. What do you prefer:
- val DefDef(mods, name, tparams, vparamss, tpt, rhs) = tree1
- treeCopy.DefDef(tree1, mods, name, tparams, vparamss, tpt, transform(rhs))
+ deriveDefDef(tree1)(transform)
Me too.
|
| | |
| |
| |
| |
| | |
Fix for trait/impl renaming in 5cbd7d06eb was incomplete.
Looks more complete now.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Have to give AnyVal a constructor and simultaneously pacify both the
typer (which knows Any has no constructor) and the jvm (which mandates a
constructor must call its superconstructor.) It's the usual angle of
adding a not-quite-right tree during parsing and then finishing it
later (in this case, in AddInterfaces.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
-- traits can extend Any, AnyRef, or AnyVal
-- classes can extend AnyRef or AnyVal but not Any.
This breaks reflection for the moment as it smuggles AnyVal so far
downstream that it's reflecting its way into bytecode (or something)
but the following test case goes five for six as anticipated.
trait Foo1 extends Any
trait Foo2 extends AnyVal
trait Foo3 extends AnyRef
class Bar1 extends Any // fail
@inline class Bar2 extends AnyVal
class Bar3 extends AnyRef
Eliminated various hijinx from definitions.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And abort calls, and unhandled exceptions, all so I can supplement the
error message with a little of the vast quantity of useful information
which we possess but do not reveal. "Details are sketchy," says the
officer tasked with investigating the crash, but no longer. Also took
the opportunity to eliminate a bunch of one-argument assertions and
requirements if I thought there was any chance I'd someday be facing
them on the wrong end of an incident.
Have you ever dreamed that instead of this experience:
% scalac -optimise <long list of files>
error: java.lang.AssertionError: assertion failed: Record Record(anonymous class JavaToScala$$anonfun$makeScalaPackage$1,Map()) does not contain a field value owner$1
Things could proceed more like this:
% scalac -optimise <long list of files>
error:
while compiling: src/compiler/scala/reflect/runtime/JavaToScala.scala
current phase: closelim
library version: version 2.10.0.rdev-4267-2012-01-25-gc94d342
compiler version: version 2.10.0.rdev-4270-2012-01-26-gd540ddf
reconstructed args: -Ydead-code -optimise -Yinline -Yclosure-elim -Yinline-handlers -d /tmp
error: java.lang.AssertionError: [etc]
You are not dreaming! IT'S ALL HAPPENING
|
| |
|
|
|
|
| |
"Induced" but not in my estimation "caused". Would like to understand
why the enclosed test case crashes under -optimise without this change
to AddInterfaces.
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/compiler/scala/reflect/internal/Symbols.scala
src/compiler/scala/reflect/internal/Types.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/library/scala/reflect/api/Trees.scala
|
| | |
| |
| |
| | |
The idea is that all operations that need to be synchronized are overriden in classes reflect.runtime.Synchronized*. Sometimes this applies to operations defined in SymbolTable, which can be directly overridden. Sometimes it is more convenient to generate SynchronizedClazz subclasses of SymbolTable classes Clazz. In the latter case, all instance creation must go over factory methods that can be overridden in the Synchronized traits.
|
| | |
| |
| |
| |
| |
| |
| | |
In lambda lift traits are renamed independently of their
implementation classes, leading in the case of a method-defined
trait to an interface called A$1 and an impl class called A$class$1
rather than A$1$class. This is now remedied.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In what feels like divine intervention as I spent my entire day
yesterday unsuccessfully attempting to understand why running atop my
new classpath code, trunk would compile and then fail like this:
build.xml:1683: Could not create type partest due to java.lang.NoSuchMethodError:
scala.tools.ant.sabbus.CompilationPathProperty$class.$init$(Lscala/tools/ant/sabbus/CompilationPathProperty;)V
I discovered the link by trying to debug a seemingly completely
unrelated problem reported by pvlugter.
On the one hand you have PathResolver/ClassPath, which by default does
not place trait implementation classes on the compilation classpath, but
does do so under -optimise (as I understand it, this is so inlining can
be performed, so let us ignore the fact that methods in traits are never
inlined, as outlined in SI-4767.)
object DefaultJavaContext extends JavaContext {
override def isValidName(name: String) = !isTraitImplementation(name)
}
Then on the other hand you have this logic in AddInterfaces:
if (impl != NoSymbol && settings.optimise.value) {
log("unlinking impl class " + impl)
...
}
The test in AddInterfaces is hardcoded to only consider the value of
-optimise. Which means that in the completely default -optimise setup,
it corresponds to the answers given by "isValidName" in JavaContext,
but nothing keeps those elements in sync. The connection to my lost day
was that, thinking I was "simplifying" my development, I had commented
out the override in DefaultJavaContext so that all classes were on the
compilation path. This caused the state of settings.optimise (still
false) and whether impl classes were on the classpath (now true) to fall
into fatal disagreement.
|
| |
|
|
|
|
| |
Changed most symbol creations to be consistent with all the others.
Opportunistically streamlined various call sites. Moved some phase-specific
methods out of Symbol to somewhere more appropriate (like that phase.)
|
| |
|
|
|
|
|
|
| |
Renamed the parameter to all the newXXX symbol creators to "newFlags"
because I've seen too many bugs which arose from having a parameter name
which shadows a field and where mistakes can inflict subtle bugs which
won't be found until much later (yes I'm trying to describe "flags" right
now.) Opportunistically cleaned up some symbol creations.
|
| |
|
|
|
|
| |
A couple locations where more work than necessary is performed
when created a typeref. (Not to mention creating bogus typerefs
applying arguments to implementation classes.)
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
LiftCode works again, now integrated with new reflection library.
Other changes: def Literal(x: Any) has been deprecated, and all its uses removed.
Modifiers has lost positions as fourth case class argument; is now a field, mirroring Tree.pos (this removes junk in patterns and makes reification simpler). Review by extempore.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think it a reasonable goal that one should be able to do the following
and have some chance of seeing anomalies before firing up advanced text
processing tools:
scalac -Ylog:all a.scala
At least until/unless we have some way of generating output in between
"user-level visible warnings" and "notice of interest once you're
peeking under the hood." As a rule of thumb, any code which echoes a
thousand lines when compiling HelloWorld should be gently shoved into
debuglog. (Or anything which is sure to print for every classfile,
every method, etc. etc.) Especially, any code which is going to simply
reference Tuple2 and then echo a line for every specialized variation of
that class is being unreasonably taxed.
While I was quietizing, I changed various 'if (settings.debug.value)
log' usages to call debuglog. Hey everyone, you can do this without
penalty now, the inliner turns around and inlines the same code, and
it's so much less unsightly. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Modified erasure so we have enough information to determine whether we
need to use scala or java erasure semantics. This fixes the runtime
failure illustrated here:
% scala29 -e 'java.util.Collections.max(null)'
java.lang.NoSuchMethodError: java.util.Collections.max(Ljava/util/Collection;)Ljava/lang/Comparable;
Review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding some Sets/Maps to perRunCaches, and eliminating ambiguously named
imports.
Did a tour of the compiler adding a few longer-lived mutable structures
to the per-run cache clearing mechanism. Some of these were not a big
threat, but there is (almost) literally no cost to tracking them and the
fewer mutable structures which are created "lone wolf style" the easier
it is to spot the one playing by his own rules.
While I was at it I followed through on long held ambition to eliminate
the importing of highly ambiguous names like "Map" and "HashSet" from
the mutable and immutable packages. I didn't quite manage elimination
but it's pretty close. Something potentially as pernicious which I
didn't do much about is this import:
import scala.collection._
Imagine coming across that one on lines 407 and 474 of a 1271 file.
That's not cool. Some poor future programmer will be on line 1100 and
use "Map[A, B]" in some function and only after the product has shipped
will it be discovered that the signature is wrong and the rocket will
now be crashing into the mountainside straightaway. 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.
|
| |
|
|
|
|
| |
Don't issue a deprecation warning if the deprecated method is being
called from a bridge method. No review.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting the mopping up now that names have some more sense of their
place in the universe. Cleaned up some heavy multi-boolean logic. Added
more documentation on the relationships between entities in Symbols and
some other compiler things which often blur together.
Fun fact: the incorrect usage of nme.ScalaObject in Contexts which I
reported when first broaching the namespace subject became a compile
time error during the writing of this patch, because there is no longer
any such thing as nme.ScalaObject. It's a little bit like magic. No
review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TermName and TypeName are exposed throughout the compiler based on what
kind of name a given abstraction ought to have. (There remain places
where one needs to create a name without knowing yet what it will be,
and those will always be Names.)
The nme object in the compiler now holds only term names. To reference a
known type name, use tpnme:
nme.List == ("List": TermName)
tpnme.List == ("List": TypeName)
The contents of nme and tpname are defined in traits, many of which
are shared, so if a name should exist only as a Type and not a
Term, it should be defined in CompilerTypeNames, but otherwise in
CompilerTermNames or CompilerCommonNames. This is partially complete but
I'm sure there are still many shared which should pick a side.
Usage of .toTermName and .toTypeName is strongly discouraged. After the
dust has settled, there will be very few places where it will make sense
to hop between namespaces like that.
There are some implicits to smooth everything out, most of which should
be removable eventually.
// these two are in no hurry to go anywhere
String => TermName
String => TypeName
// but not String => Name: def view in the compiler is no longer implicit
// these two are temporary, and can log when they kick off to help us
flush // out remaining issues of "name migration" Name => TermName
Name => TypeName
There is more work to be done before we're properly protected from
naming errors, but I will not allow another eight hour tragedy to befall
lukas or anyone else!
Review by rytz. (Formality.)
|
| |
|
|
|
|
|
|
|
|
| |
One of those annoying patches for which I apologize in advance. It's a
step toward a better world. Almost all the changes herein are simple
transformations of "x hasFlag FOO" to "x.isFoo", with the remainder
minor cleanups. It's too big to review, so let's say no review:
but I'm still all ears for input on the issues mostly outlined in
HasFlags.scala.
|
| |
|
|
|
|
|
| |
eliminated the import of ambiguously named classes from e.g.
collection.mutable, obeyed a todo in the parser regarding dropping
lbracket from statement starting tokens. No review.
|
| | |
|
| |
|
|
|
| |
Removed more than 3400 svn '$Id' keywords and related junk.
|
| |
|
|
|
|
|
|
|
| |
As a brief diversion from real work, implemented Damerau–Levenshtein
and ran it on trunk to elicit obvious misspellings. Unfortunately
they're mostly in places like compiler comments which real people never
see, but I fixed them anyway. All those English Lit majors who peruse
our sources are sure to be pleased. No review.
|
| |
|
|
|
|
|
| |
do not set the type of the implementation method to be the type of the
original one as this is done properly in cloneSymbol. no review (already
done by Martin)
|
| |
|
|
|
|
|
|
|
|
|
| |
A few yards short of the goal posts attempt at making our usage of
Throwable subclasses more consistent. This patch eliminates a lot of
ad hoc Exception/Error/etc. creation and various arbitrary choices are
rendered slightly less arbitrary. From now on let's try not to use the
word "Exception" or "Error" in the names of Throwable subclasses unless
they actually derive (and make sense to derive) from Exception or Error.
Review by community.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Trying to make typechecker faster by (1) new subtyping (2) better
implicit caches. Disallowed '42 as a symbol. Added cache method to
Mutable Maps. Better complietion in interactive.
|
| |
|
|
|
|
| |
allow using named / default arguments in self- and super constructor
calls. fixes #2050 and #2052.
|
| |
|
|
|
|
|
| |
- MethodTypes now have (params: List[Symbol])
- "copy"-methods for case classes
- the "copy" object in the compiler is now called "treeCopy"
|
| | |
|
| |
|
|
|
|
| |
In "Iterable" and in all its subclasses, "iterator" replaces "elements"
(and assorted changes).
|
| |
|
|
|
|
| |
Make sure the symbol for the implementation class of a trait has an
associated source file.
|
| | |
|
| | |
|
