macroExpandApply => macroExpand

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`.
gives a more specific signature to `computeMacroDefType`

I guess having `computeMacroDefType` is the remnant from the times when
we considered an immediate possibility of having non-defdef macros, for
instance type macros, which would be TypeDefs.

These happy early days are gone, type macros have been long buried,
and the perspectives of extensions to the existing def macro scheme are
unclear. Therefore let’s have maximally precise types right away and then
think of generalization later on, once/if we get there.
removes some copy/paste from AnalyzerPlugins

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.
unprivates important helpers in Macros.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.
hooks for typecheck and expansion of macro defs

Exposes `pluginsTypedMacroBody`, `pluginsMacroExpand`, `pluginsMacroArgs`
and `pluginsMacroRuntime` in the analyzer plugin interface. This will
make it easy to prototype changes to the macro engine without disturbing scala/scala.
humane reporting of macro impl binding version errors

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.
manifests that Namers.mkTypeCompleter is flag-agnostic

When introducing `FlagAgnosticCompleter` and `FlagAssigningCompleter`,
I have overlooked the completers created in namers. These completers
only assign type signatures, not flags, because they are only created
for symbols originating from sources and such symbols have their flags
assigned based on modifiers and source def trees when they are entered.
unprivates important helpers in Namers.scala

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 :)
hooks for naming and synthesis in Namers.scala and Typers.scala

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.
makes new typer and namer hooks more robust

Given that a hooked method is called `X`, there are now two implementations
of this method. `pluginsX` is defined in AnalyzerPlugins.scala and lets
analyzer 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 an analyzer 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.