| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Because it was its only call site.
|
| |
|
|
|
|
|
|
|
|
| |
- Language imports are preceding other imports
- Deleted empty file: InlineErasure
- Removed some unused private[parallel] methods in
scala/collection/parallel/package.scala
This removes hundreds of warnings when compiling with
"-Xlint -Ywarn-dead-code -Ywarn-unused -Ywarn-unused-import".
|
| |
|
|
|
|
|
|
| |
only trivial merge conflicts here.
not dealing with PR #4333 in this merge because there is a substantial
conflict there -- so that's why I stopped at
63daba33ae99471175e9d7b20792324615f5999b for now
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added `since` to deprecation statement
- Added unit to parameter list
- Removed usage of deprecated method polyType
- Replaced deprecated `debugwarn` with `devWarning`
- Changed switch statement to if else in order to remove a warning
- Switched implementation of `init` and `processOptions` to prevent
warning
- Replaced deprecated `Console.readLine` with `scala.io.StdIn.readLine`
- Replaced deprecated `startOrPoint` with `start`
- Replaced deprecated `tpe_=` with `setType`
- Replaced deprecated `typeCheck` with `typecheck`
- Replaced deprecated `CompilationUnit.warning` with `typer.context.warning`
- Replaced deprecated `scala.tools.nsc.util.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader`
- Replaced deprecated `scala.tools.ListOfNil` with `scala.reflect.internal.util.ListOfNil`
- Replaced deprecated `scala.tools.utils.ScalaClassLoader` with `scala.reflect.internal.util.ScalaClassLoader`
- Replaced deprecated `emptyValDef` with `noSelfType`
- In `BoxesRunTime` removed unused method and commented out unused values. Did not delete to keep a reference to the values. If they are deleted people might wonder why `1` and `2` are not used.
- Replaced deprecated `scala.tools.nsc.util.AbstractFileClassLoader` with `scala.reflect.internal.util.AbstractFileClassLoader`
|
| |\
| |
| | |
part 2 of the big error reporting refactoring
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
`typer.TyperErrorGen.MacroCantExpandIncompatibleMacrosError`
throws because the type checker it uses is at `NoContext`,
which throws by default... This default is bad and is going to change,
so make this code independent of that future sanity.
TODO: don't use mutable state to determine position for the error
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mode of macro expansion is used by the presentation compiler to
leave the original macro applications ("expandees") in the type
checked trees, annotated with the types of the expansions.
However, under some circumstances involving implicits, we would
re-expand the macro. If the macro wasn't stable, this could lead
to a type mismatch.
The originally reported problem was with the shapeless
`mkSingletonOps` macro. Its expansion had the type of a freshly-named
class local to the expansion. Upon the re-expansion, a new class
was generated, which lead to errors like:
client/Client.scala:4: error: type mismatch;
found : fresh$macro$2
required: fresh$macro$1
This commit suppressed re-expansion of the expandee by use of
the existing, tree attachment driven mechanism.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move code from Global/SymbolTable to separate Reporting traits to
start carving out an interface in scala.reflect.internal.Reporting,
with internals in scala.tools.nsc. Reporting is mixed into the cake.
It contains a nested class PerRunReporting.
Should do the same for debugging/logging.
The idea is that CompilationUnit and Global forward all reporting
to Reporter. The Reporting trait contains these forwarders, and
PerRunReporting, which accumulates warning state during a run.
In the process, I slightly changed the behavior of `globalError`
in reflect.internal.SymbolTable: it used to abort, weirdly.
I assume that was dummy behavior to avoid introducing an abstract method.
It's immediately overridden in Global, and I couldn't find any other subclasses,
so I don't think the behavior in SymbolTable was ever observed.
Provide necessary hooks for scala.reflect.macros.Parsers#parse.
See scala/reflect/macros/contexts/Parsers.scala's parse method,
which overrides the reporter to detect when parsing goes wrong.
This should be refactored, but that goes beyond the scope of this PR.
Don't pop empty macro context stack.
(Ran into this while reworking -Xfatal-warnings logic.)
Fix -Xfatal-warnings behavior (and check files): it wasn't meant to
influence warning reporting, except for emitting one final error;
if necessary to fail the compile (when warnings but no errors were reported).
Warnings should stay warnings.
This was refactored in fbbbb22946, but we soon seem to have relapsed.
An hour of gitfu did not lead to where it went wrong. Must've been a merge.
|
| |\
| |
| | |
adds MacroPlugin.pluginsIsBlackbox
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
| |
Somewhen in the 2.11.0 development cycle we started duplicating macro arguments
for increased robustness. What wasn't taken into account though is that
Tree.duplicate destroys range positions. This commit fixes the problem.
2.10.x is unaffected by this bug, because it doesn't duplicate the args yet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of mixing in FastTrack into Macros trait just have a member
with an instance of FastTrack. The motivation for this change is to reduce
the overall use of inheritance is Scala compiler and FastTrack seems like
a nice target for first step. It's an implementation detail of Scala
compiler that we are free to modify.
Previously, `fastTrack` method would be inherited from FastTrack trait and
called from clients (sub classes). The `fastTrack` method returned Map.
Now, the `fastTrack` viariable is of type `FastTrack`. In order for clients
to continue to work we had to implement three operations called by
clients: contains, apply, get.
Alternatively, we could keep the `fastTrack` method and import it in
clients. This approach is likely to be more common in the future when
bigger pieces of code get refactored.
|
| | |
|
| |
|
|
|
|
| |
Inspired by Brian McKenna's RC1 migration experience, this commit improves
macro impl binding validation in order to provide more helpful diagnostic
for this quite frequent class of errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a02e053a5dec134f7c7dc53a2c1091039218237d.
That commit lead to an error compiling Specs2:
[info] [warn] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/EditDistanceSpec.scala:6: Unused import
[info] [warn] import DiffShortener._
[info] [warn] ^
[info] [error] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/LinesContentDifferenceSpec.scala:7: exception during macro expansion:
[info] [error] java.lang.UnsupportedOperationException: Position.point on NoPosition
[info] [error] at scala.reflect.internal.util.Position.fail(Position.scala:53)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:131)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:126)
[info] [error] at org.specs2.reflect.Macros$.sourceOf(Macros.scala:25)
[info] [error] at org.specs2.reflect.Macros$.stringExpr(Macros.scala:19)
|
| |\
| |
| | |
SI-5920 enables default and named args in macros
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When producing an initial spec for macros two years ago, we sort of glossed
over named/default arguments in macro applications, leaving them for future work.
Once the aforementioned future has come, I’ve made several attempts at
making things operational (e.g. last summer), but it’s always been unclear
how to marry the quite complex desugaring that tryNamesDefaults performs
with the expectations of macro programmers to see unsugared trees
in macro impl parameters.
Here’s the list of problems that arise when trying to encode named/default
arguments of macro applications:
1) When inside macro impls we don’t really care about synthetic vals
that are typically introduced to preserve evaluation order in non-positional
method applications. When we inline those synthetics, we lose information
about evaluation order, which is something that we wouldn’t like to lose
in the general case.
2) More importantly, it’s also not very exciting to see invocations of
default getters that stand for unspecified default arguments. Ideally,
we would like to provide macro programmers with right-hand sides of those
default getters, but that is: a) impossible in the current implementation
of default parameters, b) would anyway bring scoping problems that we’re
not ready to deal with just yet.
Being constantly unhappy with potential solutions to the aforementioned
problems, I’ve been unable to nail this down until the last weekend,
when I realized that: 1) even though we can’t express potential twists in
evaluation order within linearly ordered macro impl params, we can use
c.macroApplication to store all the named arguments we want, 2) even though
we can’t get exactly what we want for default arguments, we can represent
them with EmptyTree’s, which is not ideal, but pretty workable. That’s
what has been put into life in this commit.
As a pleasant side-effect, now the macro engine doesn’t have to reinvent
the wheel wrt reporting errors about insufficient arg or arglist count.
Since this logic is intertwined with the tryNamesDefaults desugaring,
we previously couldn’t make use of it and had to roll our own logic
that checked that the number of arguments and parameters of macro applications
correspond to each other. Now it’s all deduplicated and consistent.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My first attempt at SI-6992 was about having whitebox expansions first
typecheck against outerPt and only then verify that the result is compatible
with innerPt.
That was a nice try, but soon after it went live in 2.11.0-M8, we've got
multiple reports with problems - both shapeless and then in a week specs2
started having issues with their whitebox macros.
In shapeless, typecheck against outerPt screwed up type inference, which
was more or less fixable by explicit type annotations, so I decided to
wait a bit before jumping to conclusions.
However, in specs2 the problem was more insidious. After being typechecked
against outerPt, expansions were being implicitly converted to a type
that became incompatible with innerPt. This revealed a fatal flaw of the
implemented approach - if allowed to typecheck against outerPt first,
whitebox macros could never be robust.
Now realizing that "outerPt > innerPt" doesn't work, I nevertheless wasn't
looking forward to rolling that back to "innerPt > outerPt", because that
would revive SI-6992 and SI-8048 that are highly unintuitive, especially
the latter one.
Therefore, this commit combines the permissiveness of "... > innerPt"
approaches with the robustness of "innerPt > outerPt", introducing
"WildcardType > innerPt > outerPt".
|
| |
|
|
|
|
|
|
|
|
| |
Performs the following renamings:
* scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context
* scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro
* scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context
* scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro
https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
|
| |
|
|
|
|
|
|
|
|
| |
In Jan 2013, I submitted a number of pull requests that built up a foundation
for the upcoming type macros pull request. Unfortunately, type macros
ended up being rejected, but the extra generality introduced in advance
still persisted in the compiler until now.
This commit takes care of unused generality in the macro engine,
keeping the internal implementation as well as the public API clean.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The presentation compiler is primarily interested in trees that
represent the code that one sees in the IDE, not the expansion of
macros.
This commit continues to expand macros, but adds a hook in which
the presentation compiler discards the expansion, retaining instead
the expandee. The expandee is attributed with the type of the
expansion, which allows white box macros to work. In addition,
any domain specific errors and warnings issued by the macro will
still be reported, as a side-effect of the expansion.
The failing test from the last commit now correctly resolves
hyperlinks in macro arguments.
Related IDE ticket:
https://www.assembla.com/spaces/scala-ide/tickets/1001449#
This facility is configured as follows:
// expand macros as per normal
-Ymacro-expand:normal
// don't expand the macro, takes the place of -Ymacro-no-expand
-Ymacro-expand:none
// expand macros to compute type and emit warnings,
// but retain expandee. Set automatically be the presentation
// compiler
-Ymacro-expand:discard
This leaves to door ajar for a new option:
// Don't expand blackbox macros; expand whitebox
// but retain expandee
-Ymacro-expand:discard-whitebox-only
The existing test for SI-6812 has been duplicated. One copy exercises
the now-deprecated -Ymacro-no-expand, and the other uses the new
option.
|
| |
|
|
|
| |
- Replace NoPosition with the focus of the macro application
- Focus all range positions, for example, those of spliced arguments
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Macro defs are linked to macro impls by the virtue of MacroImplBinding
structures that are persisted between compilation runs serialized within
instances of macroImpl annotations.
Along with the evolution of our macro engine, we sometimes have to evolve
the format of MacroImplBinding, which means that it has to be versioned.
Version mismatches are checked upon every macro expansion, ensuring that
macros that we expand were compiled with exactly the same version of the
macro engine that we’re running.
That’s all really cool apart from the fact that version mismatches result
in aborting the entire compilation with an obscure message without giving
a hint about the culprits.
This commit improves the situation by providing pretty per-expansion
compilation errors that tell the programmer what macro expansions are
at fault and what macro engines were used to compile them.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
This is the first commit in a pull request that makes macro engine
extensible by analyzer plugins.
Such helpers as `macroArgs` and `macroExpandWithRuntime` have proven
to be indispensable in macro paradise, so it’ll be important to have
them available to macro plugins.
|
| |
|
|
|
|
|
|
|
|
| |
Back then, when we needed separate macro expanders for both applications
and unapplications, it made sense to have two different methods that
do macro expansions.
However, after @paulp’s upgrade of the pattern matching engine, we no longer
need a dedicated expander for unapply, so I’m removing it and renaming
`macroExpandApply` to just `macroExpand`.
|
| |\
| |
| | |
makes boxity of fast track macros configurable
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, all built-in macros were assumed to be whitebox, but that’s
actually not the case. Just quasiquote macros have to be whitebox, while
the rest can be blackbox.
This also fixes SI-8091, because blackbox macros are typechecked differently
and therefore the necessary implicit conversion kicks in. If `f”...”` were
to remain a whitebox macro, then due to the changes introduced in commit
https://github.com/scala/scala/commit/a3b33419b02cafb7e2c6fed6dd96151859fc7d77
we would have to explicitly ascribe its expansion as String to achieve the same effect.
After I made reify blackbox, several tests had to be changed, because
we now explicitly ascribe the expansion with `c.Expr[T]`, which changes `toString`.
Also, a number of less obvious corrections had to be applied, because
things like `reify(<constant>).splice` have stopped being optimized away
due to `reify(<constant>)` no longer having a narrow `c.Expr[<constant>.type]`,
making it ineligible for constant folding.
Moreover, this change forced me to adjust our approach to positioning
blackbox wrappings, because after being changed to blacbox and starting using
wrappings, f”...” interpolators used in the compiler started crashing
-Yrangepos builds. Now wrapping Typed nodes are assigned with transparent
positions.
|
| |\ \
| |/
|/| |
(2.11.0-M8) duplicates macro arguments before expansion
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As discussed with Jason, this is an important dimension of defenses that
we can build to ensure robustness of the macro engine.
This commit is important in the context of the upcoming patch to the
presentation compiler that will throw away expansions and keep original
macro applications (only when run in presentation compiler mode) so that
hyperlinking in macro arguments starts working in the IDE.
Duplication of macro arguments will make sure that macro arguments, which
are going to become exposed to the IDE, can’t become corrupted by possibly
misbehaving or misguided macros.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While fixing the problem with the order of typechecks for whitebox expansions,
I realized that we’re doing redundant work when expanding blackbox macros.
Concretely, typechecking blackbox expansions looked as follows:
val expanded1 = atPos(enclosingMacroPosition.focus)(Typed(expanded0, TypeTree(innerPt)))
val expanded2 = typecheck("blackbox typecheck #1", expanded1, innerPt)
typecheck("blackbox typecheck #2", expanded1, outerPt)
Or, if we reformulate it using quasiquotes (temporarily not taking
positions into account, since they aren’t important here):
val expanded2 = typed(q”$expanded: $innerPt”, innerPt)
typed(expanded2, outerPt)
In this formulation, it becomes apparent that the first typecheck is
redundant. If something is ascribed with some type, then typechecking
the ascription against that type does nothing useful.
This is also highlights one of the reasons why it would be really nice
to have quasiquotes used in the compiler. With them, it’s easy to notice
things that would otherwise remain buried behind swaths of boilerplate.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Even though whitebox macros are supposed to be used to produce expansions
that refine advertised return types of their macro definitions, sometimes
those more precise types aren’t picked up by the typechecker.
It all started with Travis generating structural types with macros
and noticing that typer needs an extra nudge in order to make generated
members accessible to the outside world. I didn’t understand the mechanism
of the phenomenon back then, and after some time I just gave up.
Afterwards, when this issue had been brought up again in a different
StackOverflow question, we discussed it at reflection meeting, figured out
that typedBlock provides some special treatment to anonymous classes,
and it became clear that the first macro typecheck (the one that types
the expansion against the return type of the corresponding macro def)
is at fault here.
The thing is that if we have a block that stands for a desugard anonymous
class instantiation, and we typecheck it with expected type different from
WildcardType, then typer isn’t going to include decls of the anonymous class
in the resulting structural type: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L2350.
I tried to figure it out at https://groups.google.com/forum/#!topic/scala-internals/eXQt-BPm4i8,
but couldn’t dispel the mystery, so again I just gave up.
But today I had a profound WAT experience that finally tipped the scales.
It turns out that if we typecheck an if, providing a suitable pt, then
the resulting type of an if is going to be that pt, even though the lub
of the branch types might be more precise. I’m sure that reasons for this
behavior are also beyond my understanding, so I decided to sidestep this problem.
upd. Here’s Jason’s clarification: Doing thing differently would require
us to believe that "'Tis better to have lubbed and lost than never to have
lubbed at all." But the desire for efficiency trumps such sentimentality.
Now expansions of whitebox macros are first typechecked against outerPt,
the expected type that comes from the enclosing context, before being
typechecked against innerPt, the expected type that comes from the return
type of the macro def. This means that now outerPt provides the correct
expected type for the initial, most important typecheck, which makes
types more precise.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moves some code around to clearly define the concepts that the method
operates on: 1) `innerPt`, which is expected type provided by the macro
def return type, 2) `outerPt`, which is expected type provided by the
enclosing context.
Once everything is clearly defined, the gist of the expander fits in
a few lines in its end. If blackbox, do this. If whitebox, do that.
Note that unlike the subsequent commit, this commit doesn’t change
the way how macro expansion works. It just clears everything out, so that
the upcoming changes can be applied in a concise and comprehensible manner.
|
| |
|
|
|
|
|
|
|
|
| |
When an application of a blackbox macro still has undetermined type
parameters after Scala’s type inference algorithm has finished working,
these type parameters are inferred forcedly, in exactly the same manner
as type inference happens for normal methods.
This makes it impossible for blackbox macros to influence type inference,
prohibiting fundep materialization.
|
| |
|
|
|
|
|
|
|
|
|
| |
When an application of a blackbox macro expands into a tree `x`,
the expansion is wrapped into a type ascription `(x: T)`, where `T` is
the declared return type of the blackbox macro with type arguments and
path dependencies applied in consistency with the particular macro
application being expanded.
This invalidates blackbox macros as an implementation vehicle
of type providers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first commit in the series. This commit only:
1) Splits Context into BlackboxContext and WhiteboxContext
2) Splits Macro into BlackboxMacro and WhiteboxMacro
3) Introduces the isBundle property in the macro impl binding
Here we just teach the compiler that macros can now be blackbox and whitebox,
without actually imposing any restrictions on blackbox macros. These
restrictions will come in subsequent commits.
For description and documentation of the blackbox/whitebox separation
see the official macro guide at the scaladoc website:
http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html
Some infrastructure work to make evolving macros easier:
compile partest-extras with quick so they can use latest library/reflect/...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It we can only safely use vals in Definitions for top-level symbols.
Otherwise, when the IDE switches to loading the symbol from source,
we can hold on to a stale symbol, which in turn impedes implicit
materialization of TypeTags.
This commit moves (most) of the accessors for member symbols
into RunDefinitions, and changes calling code accordingly.
This is a win for presentation compiler correctness, and
might even shave of a few cycles.
In a few cases, I have had to leave a `def` to a member symbol
in Definitions so we can get to it from the SymbolTable cake,
which doesn't see RunDefinitions.
The macro FastTrack facility now correctly recreates the mapping
from Symbol to macro implementation each run, using a new facility
in perRunCaches to create a run-indexed cache.
The enclosed test recreates the situation reported in the ticket,
in which TypeTags.scala is loaded from source.
|
| | |
|
| |
|
|
|
|
|
| |
Most of this was revealed via -Xlint with a flag which assumes
closed world. I can't see how to check the assumes-closed-world
code in without it being an ordeal. I'll leave it in a branch in
case anyone wants to finish the long slog to the merge.
|
| |
|
|
|
|
|
| |
This fix provides implicit macros with an ability to affect type inference
in a more or less sane manner. That's crucial for materialization of
multi-parametric type class instances (e.g. Iso's from shapeless).
Details of the technique can be found in comments.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Adds a macro hook into the unapply part of `doTypedApply`, provides
`macroExpandUnapply` in the macro engine and applies a couple of minor
refactorings along the way (renames the ugly `macroExpand1` into
oblivion, changes the ctor of `Fingerprint` to be private and upgrades
`MacroRole` from a string to a value class).
Unapply macros haven't been approved for inclusion in 2.11.0, however
they are necessary for pattern-matching quasiquotes. Therefore I'm only
allowing them to expand for QuasiquoteClass_api_unapply.
|
| |
|
|
|
| |
Updates comments, implements accidentally forgotten IMPLPARAM_TREE,
creates a test to ensure that nothing else is overseen.
|
| | |
|
| | |
|
| |
|
|
|
| |
Following typedMacroBody, macroRuntime along with its friends has also
been moved out into a separate component.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upgrades the way that macro defs are compiled by factoring out most of
the logic in typedMacroBody and related errors in ContextErrors into an
standalone cake. This leads to tighter cohesion and better code reuse
as the cake is isolated from the rest of the compiler and is much easier
to evolve than just a method body.
Increased convenience of coding macro compilation allowed me to further
clarify the implementation of the macro engine (e.g. take a look at
Validators.scala) and to easily implement additional features, namely:
1) Parameters and return type of macro implementations can now be plain
c.Tree's instead of previously mandatory c.Expr's. This makes macros more
lightweight as there are a lot of situations when one doesn't need to
splice macro params (the only motivation to use exprs over trees). Also
as we're on the verge of having quasiquotes in trunk, there soon will be
no reason to use exprs at all, since quasiquotes can splice everything.
2) Macro implementations can now be defined in bundles, standalone cakes
built around a macro context: http://docs.scala-lang.org/overviews/macros/bundles.html.
This further reduces boilerplate by simplifying implementations complex
macros due to the fact that macro programmers no longer need to play
path-dependent games to use helpers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Macro impl bindings now store more information in signatures.
Previously it was a flattened List[Int] corresponding to flattened paramss,
now it's List[List[Int]] to preserve the lengths of parameter lists.
Also now we distinguish between c.Expr parameters and others.
Previously actual and reference macro signatures were represented as
tuples of vparamss, rets, and sometimes tparams. Now they are all
abstracted behind MacroImplSig.
Finally this patch provides better error messages in cases of
argsc <-> paramsc and argc <-> paramc mismatches.
|
