| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Guess that was a bad choice of class. No review.
|
|
|
|
|
|
|
|
| |
It represents a lot of work because the mutation flies fast and furious
and you can't even blink at these things without upsetting them. They're
a little hardier now, or at least we stand a better chance of changing
them. Open season on review.
|
| |
|
| |
|
|
|
|
|
| |
Don't truncate errors or warnings. No review.
|
|
|
|
|
|
| |
Discovered an overloaded method with multiple unimplemented variants
only had one listed. Fixed, no review.
|
|
|
|
|
|
| |
Propagate varargs flag from object methods to static forwarders so java
will recognize them as varargs.
|
| |
|
|
|
|
|
|
|
| |
Fixed problem when running under -Xcheckinit for the code.scala test by
avoiding accessing an unitialized variable. Good catch, -Xcheckinit!
Review by extempore.
|
|
|
|
|
|
| |
"phase.id <= currentRun.typerPhase.id" hurts my brain in all these
convoluted conditionals. No review.
|
|
|
|
|
|
| |
First end-to-end implementation of a runtime reflexive compiler that
generates and loads bytecodes. Review by szeiger.
|
|
|
|
|
| |
Trying to fix getLinkPos problem reported by Mirco. Review by dotta.
|
| |
|
| |
|
|
|
|
|
| |
Suppresses ProductN parent for case classes. No review.
|
| |
|
| |
|
|
|
|
|
| |
Pushed NPE defense in NoSourceFile.file out another level.
|
| |
|
|
|
|
|
|
| |
Propagate Error in repN. I have no time for a test case, I will gladly
take a contribution. References SI-1100, Closes SI-5108, No review.
|
|
|
|
|
|
| |
Pinpointed line which gave us SI-3882. In case a remedy suggest itself
to you, review by dragos.
|
|
|
|
|
|
| |
Starting to see a glimmer of the other side now. I nudged a few things
into more sensible places. No review.
|
| |
|
|
|
|
|
|
| |
It's hidden behind -Xlint and pretty specific, but makes me feel better
anyway. References SI-4762, no review.
|
|
|
|
|
| |
One little tiny oversight, those positions are finicky. No review.
|
| |
|
|
|
|
|
|
|
| |
I was hoping to be further than this by now ("Accursed mutants!" *shakes
fist*) but you can't deny we've come a long way. Review is welcome, but
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
iff the matching monad is Option (the default MatchingStrategy),
optimize flatMap/orElse/guard to the equivalent if-then-else (otherwise,
emit flatMap/orElse,... calls)
also, triggering support for <outer> when opt.virtPatmat (was
opt.experimental)
no review
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
explicitouter support for virtpatmat synthetic <outer> is turned into the actual outer accessor since pattern matching virtualisation is done during typer, not explicitouter like the real pattern matcher, we don't know what the outerAccessor is yet when emitting outer checks -- thus use a synthetic select that is transformed into the real thing during explicitouter
no review
|
|
|
|
|
|
|
|
| |
setting the stage for the virtualizing pattern matcher no actual changes
though
no review
|
|
|
|
|
|
|
|
| |
misc fixes while working on virtualizing pattern matching not directly
related to pattern matching, though
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of barring types that have been skolemized after the TypeVar
they're being compared against, (isRelatable) simply remember when a
type var is compared to a type skolem from a later skolemization level
finally, repack the solution for the type var into a fresh existential
if the compared level exceeded ours
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
|
| |
|
|
|
|
|
|
|
|
| |
implemented my own feedback from
https://codereview.scala-lang.org/fisheye/cru/SR-1022#CFR-23393
no review
|
|
|
|
|
|
|
|
| |
Having I think established this isn't merely a dance around the maypole,
I'm going to continue breaking down Namers because it's hard to figure
out where my stubbing mechanism is colliding with the existing logic.
Getting there, no review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Contributed by Todd Vierling with minor mods by extempore. This is an
obvious extension of AbstractFunctionN which I had some issue making
work at the time. Sounds kind of pitiful given that the compiler patch
is about two lines, but let's all agree to believe it was a different
world then.
This example program is impacted as follows:
class A {
def f: PartialFunction[Any, Int] = { case x: String => 1 }
def g: PartialFunction[Any, Int] = f orElse { case x: List[_] => 2 }
def h: PartialFunction[Any, Int] = g orElse { case x: Set[_] => 3 }
}
Before: 34943 bytes of bytecode
After: 4217 bytes of bytecode
A mere 88% reduction in size. "'Tis but a trifle!" Closes SI-5096,
SI-5097.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Tweaks to Any and AnyRef documentation, courtesy of Seth Tisue. No
review.
|
|
|
|
|
| |
Added some reverse engineered documentation to Namers, no review.
|
|
|
|
|
|
|
| |
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.
|