| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
First end-to-end implementation of a runtime reflexive compiler that
generates and loads bytecodes. Review by szeiger.
|
| | |
|
| |
|
|
|
| |
Suppresses ProductN parent for case classes. No review.
|
| | |
|
| |
|
|
|
|
| |
It's hidden behind -Xlint and pretty specific, but makes me feel better
anyway. References SI-4762, no review.
|
| | |
|
| |
|
|
|
|
|
| |
This has been failing the Xcheckinit build for weeks and is now failing
the regular build too. I'm checking in some hairy stuff and I'd like to
make a good impression on it. Review by odersky.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
at least one imminent TODO: undo hardwired generation of if/then/else,
and decide based on type whether to call flatMap/orElse or inline those
methods from Option
review by extempore
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
a type var's constraint now also tracks whether the type var was
compared to a stable type
if it was, we probably shouldn't widen the type argument that's inferred
for this var, as the result will surely fail to type check
NOTE: must be enabled using -Xexperimental
review by extempore
|
| |
|
|
|
|
|
|
|
|
|
|
| |
can't believe I missed that one...
closes SI-5033
more complete test case to make sure the multi-arglist case works as
well
no review
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
however, it must be possible to inline Ensuring, ArrowAssoc methods
renamed the public val x to something a little less intrusive
fixed check file to reflect better error message (see! it wasn't that uncommon for people to write `foo.x` -- NEWS AT ELEVEN)
no review
|
| |
|
|
|
|
|
|
| |
If extempore is going to fix the hard bugs then first he is going to
make them less hard to fix. The major work of interest in here is the
decomplification of the bitmap logic. Hopefully this will come in handy
for anyone wishing to try out other encodings.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Impressed at the amount of ticket traffic for an unadvertised internal
method. All the more reason to work toward that support repl API. Don't
worry, it'll come. Closes SI-4899, no review.
|
| |
|
|
|
|
|
|
| |
Don't mark shutdown hooks as daemon threads, although it does not seem
to make any difference. Instead have the code which waits for all
threads to be complete be smarted about which codes to monitor. No
review.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Reverting r25787 (caused test.scaladoc failures on certain systems)
|
| |
|
|
|
|
|
|
|
|
|
| |
An interesting bug during cleanup: runtime checks on the target of a
structural invocation duplicated the selection without regard for the
fact that it might be an expression. So if the name of the method being
invoked allowed the possibility that the target was a primitive type
(such as "toInt") the expression would be evaluated three times.
Closes SI-5080, 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.
|
| |
|
|
|
|
| |
I verified this creates identical library bytecode so I anticipate no
regressions. Review by prokopec anyway.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Reverted r25823 as it breaks specialization of traits.
|
| |
|
|
|
|
| |
Don't require a tableswitch if the matcher elected not to emit one
because there were so few cases. No review.
|
| |
|
|
|
| |
Closes SI-5071, review by prokopec.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It took me a long time to find a trivial error while adjusting the
annotation packages, so I spent even longer trying to make sure next
time it would take me less time. It's the usual business of eliminating
duplication and unnecessary indirection.
Behavioral note: there was no consistency or deducible reasoning
regarding when annotation checks would be performed against the
typeSymbol directly (thus excluding annotation subclasses) or when they
would do a subclass check. I saw no reason it shouldn't always be a
subclass check; if the annotation isn't supposed to be subclassed it
should be final, and if it is, then the subclasses had probably better
not stop exhibiting the behavior of the base class.
Example: this now draws deprecated warnings, but did not before.
class bippy extends deprecated("hi mom", "burma shave")
@bippy def f = 5
(The deprecation message isn't printed so we're not there yet, but
closer.)
There is some new internal documentation on annotations, sadly lacking
in my famous ascii diagrams, and some new conveniences. Review by rytz.
|
| |
|
|
|
|
|
|
|
|
|
| |
(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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add "Google tokens for Scala" for symbolic names on Scaladoc. Review by
ureche.
We can't use Scala's symbolic names on Google. Instead of waiting
Google, we'll introduce mapping from the names to equivalent searchable
representations. This idea proposed by Grzegorz Kossakowski.
https://groups.google.com/group/scala-internals/browse_thread/thread/413
dbc691542f76f
|
| |
|
|
|
| |
See SI-5060. Review by odersky.
|
| | |
|
| |
|
|
|
|
| |
Did something eat some whitespace? I don't know. This is almost the same
commit as r25783, but with different whitespace. No review.
|
| |
|
|
|
|
| |
Until I have a second to figure out how a checkfile whose contents are
*recorded from running the test case* can fail to match. No review.
|
| |
|
|
|
|
| |
Add a small "template engine" and separete HTML from Scaladoc's source
code. Review by ureche.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Hard to believe a bug like this can exist this long. Cay Horstman showed
me.
// Hey, where's my eacute?
scala> <city name="San José"/>.attributes foreach println
name="San Jos&;"
No review.
|
| |
|
|
|
|
|
|
| |
The comment in SyntheticMethods and the comment in the serialization
test said exactly opposite things. The logic at work all seems to be
invalid anyway since nested objects are not treated like lazy vals, they
have no bitmap. Serialize everything serializable. Review by plocinic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old Man Reflection is coming home and he's not going to like finding
out a bunch of beans have moved into his reflecting room. We had better
evict those guys before he blows his stack.
scala.reflect.*Bean* --> scala.beans.*
scala.beans, that's kind of a fancy package name for some beans. I
figure it's time to start fishing or cutting bait on this kind of thing.
I don't even know what beans are, but if we're going to have them in the
mainline, the least surprising place to find them is scala.beans. If we
don't want to put them in scala.beans for whatever reason, then I say
they don't belong in trunk at all.
Bonus round:
scala.annotation.target --> scala.beans.meta
I don't know if there is any more unfortunate name for a package
possible than "target". Maybe ".svn" or ".git" if you could have dots
in package names. Package CVS wouldn't hit too hard these days. Package
lib_managed? I'll try to come up with something. In any case this golden
opportunity could not be squandered.
There is a new starr included, because GenJVM contains all kinds of
shooting-from-the-hip Bean-related name hardcoding. (Yes, still. I ran
out of stones. So a few birds escape with their lives... this time.)
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Following Paul's detective work, fixed Java class loading in reflection.
Moved test code.scala into checkin build. Yay!
|
| |
|
|
|
| |
No review.
|
