| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
The the word 'the' is often used twice. Fix that.
|
| |
|
|
|
| |
This commit corrects many typos found in scaladocs and comments.
There's also fixed the name of a private method in ICodeCheckers.
|
| |
|
|
|
|
|
|
| |
Initial implementation of pluginsEnterStats was incorrect, because I got
the foldLeft wrong, making it perpetuate the initial value of stats.
This worked fine if zero or one macro plugins were active at a time,
but broke down if there were multiple of such plugins (concretely,
I discovered this issue when trying to marry macro paradise with scalahost).
|
| |
|
|
|
|
|
|
|
|
| |
This is an important omission in the current macro plugin API, which was
designed before the blackbox vs whitebox separation was implemented.
Even if one overrides pluginsTypedMacroBody and pluginsMacroExpand,
that would still be not enough to write a custom macro expander, because
typedImplicit1 uses isBlackbox, which is tightly coupled with the standard
way of reading/writing macro signatures.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Interestingly enough, despite of the implementation surface being
quite noticeable, it is enough to hijack just `enterSym` and typechecking
of stats for packages, templates and blocks in order to enable macro annotations.
That and `ensureCompanionObject`, which I couldn't abstract away so far.
An architectural note: given that a hooked method is called `X`,
there are two implementations of this method. `pluginsX` is defined in
AnalyzerPlugins.scala and lets macro plugins customize `X`.
`standardX` is defined next to `X` and provides a default implementation.
Finally `X` is changed to trivially forward to `pluginsX`.
Existing and future callers of `X` now can be completely oblivious of the
introduced hooks, because calls to `X` will continue working and will be
correctly hooked. This makes the infrastructure more robust.
The only downside is that in case when a macro plugin wants to call
into the default implementation, it needs to call `standardX`, because
`X` will lead to a stack overflow. However, in my opinion this not a big
problem, because such failures are load and clear + for every `pluginsX`
we actually provide documentation that says what is its standard impl is.
|
| |
|
|
|
|
|
|
|
|
| |
This is the first of two commits that enable hooks necessary to implement
macro annotations in an honest, hackless compiler plugin.
This particular commit turns certain helpers into public methods. Of course,
there is a probability that with the evolution of macro paradise, I will need
more helper methods, and those will have to be called via reflection, but
at least for now it's nice to have a reflection-less plugin :)
|
| |
|
|
|
|
|
|
|
| |
Creates MacroPlugin, a sister interface of AnalyzerPlugin in the namer/typer
extensibility interface.
Exposes `pluginsTypedMacroBody`, `pluginsMacroExpand`, `pluginsMacroArgs`
and `pluginsMacroRuntime` in the macro plugin interface. This will
make it easy to prototype changes to the macro engine without disturbing scala/scala.
|
| |
|
|
|
|
| |
Abstracts away the foldLeft-based iteration pattern behind CumulativeOp[T].
In order to avoid performance regressions, `pluginsPt` and `pluginsTyped`
are special-cased for empty lists of analyzer plugins.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have lots of core classes for which we need not go through
the symbol to get the type:
ObjectClass.tpe -> ObjectTpe
AnyClass.tpe -> AnyTpe
I updated everything to use the concise/direct version,
and eliminated a bunch of noise where places were calling
typeConstructor, erasedTypeRef, and other different-seeming methods
only to always wind up with the same type they would have received
from sym.tpe. There's only one Object type, before or after erasure,
with or without type arguments.
Calls to typeConstructor were especially damaging because (see
previous commit) it had a tendency to cache a different type than
the type one would find via other means. The two types would
compare =:=, but possibly not == and definitely not eq. (I still
don't understand what == is expected to do with types.)
|
| |
|
|
|
|
|
|
|
|
| |
Conflicts:
src/compiler/scala/tools/nsc/typechecker/Contexts.scala
src/compiler/scala/tools/nsc/typechecker/Namers.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/continuations/plugin/scala/tools/selectivecps/CPSAnnotationChecker.scala
src/reflect/scala/reflect/internal/AnnotationCheckers.scala
src/reflect/scala/reflect/internal/Symbols.scala
|
|
|
AnnotationCheckers are insufficient because they live outside the
compiler cake and it's not possible to pass a Typer into an annotation
checker.
Analyzer plugins hook into important places of the compiler:
- when the namer assigns a type to a symbol (plus a special hook for
accessors)
- before typing a tree, to modify the expected type
- after typing a tree, to modify the type assigned to the tree
Analyzer plugins and annotation checker can be activated only during
selected phases of the compiler.
Refactored the CPS plugin to use an analyzer plugin (since
adaptToAnnotations is now part of analyzer plugins, no longer
annotation checkers).
|
