| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Changes macroExpand to accommodate expansion schemes different from the
currently supported one.
As a bonus, which follows clarification of the macro expansion logic,
this refactoring fixes suppression of macro expansions, which
previously didn't work with delayed expansion.
|
| |
|
|
|
| |
Applies a minor renaming that I failed to thoroughly perform
in the last pull request which refactored parent types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similarly to global.emptyValDef, which is a dummy that stands for an
empty self-type, this commit introduces global.pendingSuperCall, which
stands for a yet-to-be-filled-in call to a superclass constructor.
pendingSuperCall is emitted by Parsers.template, treated specially by
Typers.typedParentType and replaced with a real superclass ctor call
by Typers.typedTemplate.
To avoid copy/paste, this commit also factors out and unifies dumminess
of EmptyTree, emptyValDef and pendingSuperCall - they all don't have a
position and actively refuse to gain one, same story for tpe.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment parser does too much w.r.t handling of parent types.
It checks whether a parent can have value arguments or not and
more importantly, it synthesizes constructors and super calls.
This approach is fundamentally incompatible with upcoming type macros.
Take for example the following two snippets of code:
`class C extends A(2)`
`class D extends A(2) with B(3)`
In the first snippet, `A` might be a type macro, therefore the super call
`A.super(2)` eagerly emitted by the parser might be meaningless. In the
second snippet parser will report an error despite that `B` might be
a type macro which expands into a trait.
Unfortunately we cannot simply augment the parser with the `isTypeMacro`
check. This is because to find out whether an identifier refers to a type
macro, one needs to perform a typecheck, which the parser cannot do.
Therefore we need a deep change in how parent types and constructors
are processed by the compiler, which is implemented in this commit.
|
| |
|
|
|
|
|
|
|
| |
Builds a starr that uses stuff from scala.reflect.macros for macro activities.
Crucial makro thingies (such as makro.Context or makro.internal.macroImpl)
are temporarily left in place, because they are necessary for previous starr.
Macro tests will be fixed in a dedicated commit, so that they don't pollute
meaningful commits, making the life easy for reviewers and spelunkers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before reflection refactoring, macro contexts only exposed a mirror.
Now it's time to expose both a universe (the compiler instance) and
a mirror (a macro-specific symbol resolver).
By the way, speaking of mirrors. Macro contexts have their own mirror,
which is different from compiler's rootMirror. This is done because
macros need to be able to resolve stuff from empty package.
Reflection refactoring brought major changes to runtime evaluation,
which got dropped from universes and now requires scala-compiler.jar.
However there are macro users, who would like to do eval inside macros.
To help them we expose `libraryClassLoader` to manually build toolboxes,
and also a simple-to-use `c.eval` method.
I've also sneakily introduced `c.parse`, because it's something that
has also been frequently requested. Moreover, it might help Scaladoc.
So I decided that it might be worth it to add this new functionality.
|
| |
|
|
|
|
|
|
|
| |
As a result, hardwired macros don't need implementation stubs.
This is very important, because in a few commits scala.reflect.makro.Context
will move out from scala-library.jar.
Also adding fast track entries doesn't require jumping through hoops
with PDTs. It's as simple as defining PartialFunction[Tree, Any].
|
| |
|
