| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/...
|
|
The macro def <-> macro impl correspondence check compares names of the
corresponding parameters in def and impl and reports an error if they
don't match. This was originally designed to avoid confusion w.r.t named
arguments (which ended up being never implemented as described in SI-5920).
Sometimes parameter names are generated by the compiler, which puts the
user in a tough position. Luckily, there's an escape hatch built it, which
omits the name correspondence check if one of the parameters is SYNTHETIC.
Everything went well until we realized that evidences generated by
context bounds aren't SYNTHETIC, which led to the bug at hand.
Marking auto-generated evidence parameters SYNTHETIC was only the first
step, as the correspondence checker uses parameter symbols, not parameter
trees. Why's that a problem? Because SYNTHETIC doesn't get propagated from def
trees to their underlying symbols (see ValueParameterFlags).
Unfortunately one cannot just change ValueParameterFlags, because that
would break printouts generated in TypeDiagnostics, which is designed to not
print synthetic symbols. Thus we modify methodTypeErrorString in
TypeDiagnostics to always print synthetic symbols.
Therefore now we propagate all paramSym.flags when doing correspondent sweeps
to keep them in sync between def trees and their underlying symbols. This
fixes the problem.
|