diff options
author | Paul Phillips <paulp@improving.org> | 2012-02-25 20:43:37 -0800 |
---|---|---|
committer | Paul Phillips <paulp@improving.org> | 2012-02-25 21:41:19 -0800 |
commit | da12146b8f3a5215e9685cd978d898131f67f1eb (patch) | |
tree | d00f643dcfb3b08fbe2842f46a4ed54b520cf236 /project | |
parent | 7970e0d949bd8b3a5e8069e377d007351327ce80 (diff) | |
download | scala-da12146b8f3a5215e9685cd978d898131f67f1eb.tar.gz scala-da12146b8f3a5215e9685cd978d898131f67f1eb.tar.bz2 scala-da12146b8f3a5215e9685cd978d898131f67f1eb.zip |
Toward a higher level abstraction than atPhase.
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.)
Diffstat (limited to 'project')
0 files changed, 0 insertions, 0 deletions