| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
detect partialfunction in cpsannotationchecker
emit apply/isDefinedAt if PF has @cps targs (applyOrElse can't be typed)
further hacky improvements to selective anf
better try/catch support in selective cps using freshly minted anonfun match
make virtpatmat resilient to scaladoc (after uncurry, don't translate matches
TODO: factor out translation all together so presentation compiler/scaladoc can skip it)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
typers&patmatvirtualizer have ad-hoc support for dropping annotations
in a way that makes the CPS plugins happy... this is not ideal,
but unless virtpatmat runs after the plugin phases, I don't see how to solve it
running virtpatmat after the CPS plugin would mean the pattern matching evaluation
cannot be captured by CPS, so it's not even desirable to move it to a later phase
- typedIf must lub annotated types
- drop selector.tpe's annotations
- drop annots in matchEnd's argument type
- deal with annots in casts synth by in virtpatmat
(drop them from type arg to asInstanceof, recover them using type ascription)
- workaround skolemize existential dropping annots
CPS is the main reason why typedMatchAnonFun is not used anymore,
and PartialFunction synthesis is moved back to uncurry (which is quite painful due to labeldefs being so broken)
we can't synth partialfunction during typer since T @cps[U] does not conform to Any,
so we can't pass it as a type arg to PartialFunction, so we can't type a cps-transformed PF
after the CPS plugin, T @cps[U] becomes ControlContext[...], which is a type we can pass
to PartialFunction
virtpatmat is now also run until right before uncurry
(so, can't use isPastTyper, although it means more or less the same thing -- we don't run after uncurry)
the main functional improvements are in the selective ANF transform
its treatment of labeldefs was broken: for example,
LabelDef L1; LabelDef L2 --> DefDef L1; L1(); DefDef L2; L2()
but this does not take into account L1 may jump over L2 to another label
since methods always return (or fail), and the ANF transform generates ValDefs
to store the result of those method calls, both L1 and L2 would always be executed
(so you would run a match with N cases N times, with each partial run starting at a later case)
also fixed a couple of weird bugs in selective anf that caused matches to be duplicated
(with the duplicate being nested in the original)
since label defs are turned into method defs, and later defs
will be nested in the flatMap calls on the controlcontext
yielded by earlier statements, we reverse the list of method
definitions, so that earlier (in the control flow sense) methods
are visible in later ones
selective CPS now generates a catch that's directly digestible by backend
|
| |
|
|
| |
This reverts commit da35106f81a5c24e78ff51c95e10052ad4f23b18.
|
| |
|
|
|
|
|
|
| |
Avoid explicit type arguments which don't conform to bounds
where they could be successfully inferred.
I had to disable one "neg" test which is no longer neg.
Can anyone clue me in as to whether it is important?
|
| | |
|
| |
|
|
|
|
|
| |
Removed all the trailing whitespace to make eugene happier.
Will try to keep it that way by protecting at the merge level.
Left the tabs in place because they can't be uniformly changed
to spaces, some are 2, some are 4, some are 8, whee.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |\ |
|
| | |
| |
| |
| | |
multi-argument list methods.
|
| |/ |
|
| |
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are too many potential optimizations unavailable to us due to the
lack of bright lines among different kinds of symbols. For instance the
difference between a TypeSymbol which represents a type alias and one
which represents an abstract type is only whether the DEFERRED flag
is set. This creates issues.
1) There are many (many) places where tests are performed on every symbol
which could be done more efficiently and (especially) more verifiably
correctly with polymorphism.
2) TypeRefs based on those symbols are also checking that flag
constantly, in perpetuity. A symbol created as an alias is never (to the
best of my knowledge) going to intentionally morph into one representing
an abstract type, nor vice versa.
3) One has no guarantees, because anyone can set or reset the DEFERRED
flag at any time.
So tackling more than one problem at once herein:
1) I created canonical symbol creation points which take the flags as
an argument, so that there can be a difference between initializing a
symbol's flags and setting/resetting them at arbitrary times.
2) I structured all the symbol creators to take arguments in the
same order, which is:
def newXXX(name: Name, ..., pos: Position = NoPosition, flags: Long = 0L)
(Where "..." is for those symbols which require something
beyond the name to create, such as a TypeSkolem's origin.)
The name is first because it's the only always required argument.
I left but deprecated the variations which take (pos, name).
3) I created subclasses of TypeRef based on the information which
should be stable from creation time onward:
- args or no args?
- abstract type, type alias, or class?
2x3 == 6 and that's how many subclasses of TypeRef there are now. So
now, for example, every TypeRef doesn't have to carry null symInfoCache
and thisInfoCache fields for the benefit of the minority which use them.
I still intend to realize the gain possible once we can evade the fields
for pre and args without losing pattern matcher efficiency.
|
| |
|
|
|
|
|
|
| |
Several large helpings of tedium later, fewer strings are being
discarded like so much refuse. Some names now cache a String, but only
"named Names", so it's not very many and they pay for themselves pretty
quickly. Many fewer name-related implicit conversions now taking place.
A number of efficiency related measures.
|
| |
|
|
|
|
| |
We're not buying anything with it off by default. Added a
-P:continuations:disable option to disable. -P:continuations:enable
lives on as a no-op. Review by @odersky.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AnnotationInfo inertia takes me into continuations.
And kept carrying me until I was carried away. The changes are mostly of
the janitorial variety, just doing my part to make the interesting logic
visible without being buried in low level compiler plumbing.
Added at least one seriously convenient convenience method:
tree modifyType fn
// equivalent to if (tree.tpe == null) tree else tree setType fn(tree.tpe)
This is the analogue to the recently added:
symbol modifyInfo fn
// same idea
It's like having our carpets steam cleaned when we can keep pushing
until machinery stays in the machine and the relevant logic stands
gloriously on top. You'll eventually exclaim, "I didn't even know these
carpets were that color!"
|
| | |
|
| |
|
|
|
|
| |
Scaladoc enhancements to continuations package for docspree. Review by
rompf
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Beginning to document scala.util.continuations with a use case.
Authored by Chris League and Roland Kuhn.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Refactored reflection into reflect.api and reflect.internal. Severed the
last remaining dependency on reflect.generic. Review by extempore.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introduce NullaryMethodType to disambiguate PolyType
motivation:
given `def foo[T]: (T, T)` and `type Foo[T] = (T, T)`,
`foo.info` and `TypeRef(_, Foo, Nil).normalize` are both
`PolyType(List(T), Pair[T, T])`
uncurry has been relying on an ugly hack to distinguish these
cases based on ad-hoc kind inference without this distinction,
the type alias's info (a type function) would be transformed to
`PolyType(List(T), MethodType(Nil, Pair[T, T]))`
anonymous type functions are being used more often (see #2741, #4017,
#4079, #3443, #3106), which makes a proper treatment of PolyTypes more
pressing
change to type representation:
PolyType(Nil, tp) -> NullaryMethodType(tp)
PolyType(tps, tp) -> PolyType(tps, NullaryMethodType(tp)) (if the polytype denoted a polymorphic nullary method)
PolyType(Nil, tp) is now invalid
the kind of a PolyType is * iff its resulttype is a NullaryMethodType or a MethodType (i.e., it's a polymorphic value)
in all other cases a PolyType now denotes a type constructor
NullaryMethodType is eliminated during uncurry
pickling:
for backwards compatibility, a NullaryMethodType(tp) is still pickled as a PolyType(Nil, tp),
unpickling rewrites pre-2.9-pickled PolyTypes according to the expected kind of the unpickled type (similar to what we used to do in uncurry)
a pickled PolyType(Nil, restpe) is unpickled to NullaryMethodType(restpe)
a pickled PolyType(tps, restpe) is unpickled to PolyType(tps, NullaryMethodType(restpe)) when the type is expected to have kind *
the rewrite probably isn't complete, but was validated by compiling
against the old scalacheck jar (which has plenty of polymorphic nullary
methods) nevertheless, this commit includes a new scalacheck jar
summary of the refactoring:
* PolyType(List(), tp) or PolyType(Nil, tp) or PolyType(parms, tp) if params.isEmpty ==> NullaryMethodType(tp)
* whenever there was a case PolyType(tps, tp) (irrespective of tps isEmpty), now need to consider the
case PolyType(tps, NullaryMethodType(tp)); just add a case NullaryMethodType(tp), since usually:
- there already is a PolyType case that recurses on the result type,
- the polytype case applied to empty and non-empty type parameter lists alike
* tp.resultType, where tp was assumed to be a PolyType that represents a polymorphic nullary method type
before, tp == PolyType(tps, res), now tp == PolyType(tps, NullaryMethodType(res))
* got bitten again (last time was dependent-method types refactoring)
by a TypeMap not being the identity when dropNonConstraintAnnotations
is true (despite having an identity apply method). Since asSeenFrom
is skipped when isTrivial, the annotations aren't dropped. The
cps plugin relies on asSeenFrom dropping these annotations for
trivial types though. Therefore, NullaryMethodType pretends to
never be trivial. Better fix(?) in AsSeenFromMap: `if(tp.isTrivial)
dropNonContraintAnnotations(tp) else ...`
TODO: scalap and eclipse
review by odersky, rytz
|
| |
|
|
|
|
| |
Warded off an NPE (which only arose on erroneous code) in the
continuations plugin. Closes #4132, no review.
|
| |
|
|
|
|
|
| |
one deprecation, one unchecked, and one "other", each of which
volunteers no mechanism for suppression. (It would be nice to change
this.) No review.
|
| |
|
|
|
|
|
| |
Moved ClassfileAnnotation/StaticAnnotation/Annotation/TypeConstraint
into scala.annotation and enabled the deprecated type aliases in scala.*
to point there. Also enclosed is a new starr to bootstrap. No review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mopping up after the deprecation of exit and error. It is decidedly
non-trivial (at least for the IDE-impaired) to be completely sure of
which error function was being called when there were about twenty with
the same signature in trunk and they are being variously inherited,
imported, shadowed, etc. So although I was careful, the possibility
exists that something is now calling a different "error" function than
before. Caveat programmer.
(And let's all make it our policy not to name anything "error" or "exit"
from here on out....) No review.
|
| |
|
|
|
|
|
|
|
| |
the same issues as JavaConversions with respect to overloading implicit
methods making them inaccessible to view bounds. Fixed JavaConverters.
Added a warning for when people overload parameterized implicits: in
almost all cases the name is irrelevant so there's little point in
unwittingly suffering degraded functionality. No review.
|
| |
|
|
|
|
|
|
|
|
|
| |
Determined that half a dozen ways of checking for varargs and
by-name-ness in param lists exceeded the legal limit. Also assessed that
names which are only used as type names would be a lot easier to deal
with if we created them as type names up front. Performed the changes
implied by the preceding along with a partial cleanup on TreeInfo which
one can see hasn't had a good look in a long time. (And still hasn't.)
No review.
|
| |
|
|
|
|
|
|
|
| |
The inliner now looks harder for method implementations. In addition
to the receiver, it will find those in directly mixed in traits and
in superclasses. It still won't find those in traits mixed only into
superclasses, as that didn't come quite so easily. Closes #3234 but I'll
be opening up another ticket. Review by dragos.
|
| |
|
|
|
|
|
|
| |
transformer. It now aligns tree nodes that contain
names to the symbol name that was substituted. Before
this change identifiers may refer to one symbol, while
the name they carry would resovlve to another one.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
fixes the unfounded "name clash between inherited members" error. review
by dragos.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
continuations plugin will now report a nice error message if it is not
enabled and encounters an @cps expression. review by rytz
|
| |
|
|
|
|
|
|
|
| |
method on Iterator called collect which I had to remove, because if
the method is overloaded it puts a bullet in the type inference, an
intolerable result for a function which takes a partial function as its
argument. I don't think there's much chance of confusion, but I put a
migration warning on collect just in case. No review.
|
| | |
|
| |
|
|
|
|
| |
added support for continuations in try/catch blocks. review by
community.
|
| | |
|
| |
|
