Merely traverses the target and records symbols local to the reifee along with their metalevels.

Splits list into a list of groups where subsequent elements are considered similar by the corresponding function.

Example:

> group(List(1, 1, 0, 0, 1, 0)) { _ == _ } List(List(1, 1), List(0, 0), List(1), List(0))

Makes sense of cross-stage bindings.

Analysis of cross-stage bindings becomes convenient if we introduce the notion of metalevels. Metalevel of a tree is a number that gets incremented every time you reify something and gets decremented when you splice something. Metalevel of a symbol is equal to the metalevel of its definition.

Example 1. Consider the following snippet:

reify { val x = 2 // metalevel of symbol x is 1, because it's declared inside reify val y = reify{x} // metalevel of symbol y is 1, because it's declared inside reify // metalevel of Ident(x) is 2, because it's inside two reifies y.splice // metalevel of Ident(y) is 0, because it's inside a designator of a splice }

Cross-stage bindings are introduced when symbol.metalevel != curr_metalevel. Both bindings introduced in Example 1 are cross-stage.

Depending on what side of the inequality is greater, the following situations might occur:

1) symbol.metalevel < curr_metalevel. In this case reifier will generate a free variable that captures both the name of the symbol (to be compiled successfully) and its value (to be run successfully). For example, x in Example 1 will be reified as follows: Ident(newFreeVar("x", IntTpe, x))

2) symbol.metalevel > curr_metalevel. This leads to a metalevel breach that violates intuitive perception of splicing. As defined in macro spec, splicing takes a tree and inserts it into another tree - as simple as that. However, how exactly do we do that in the case of y.splice? In this very scenario we can use dataflow analysis and inline it, but what if y were a var, and what if it were calculated randomly at runtime?

This question has a genuinely simple answer. Sure, we cannot resolve such splices statically (i.e. during macro expansion of reify), but now we have runtime toolboxes, so noone stops us from picking up that reified tree and evaluating it at runtime (in fact, this is something that Expr.splice does transparently).

This is akin to early vs late binding dilemma. The prior is faster, plus, the latter (implemented with reflection) might not work because of visibility issues or might be not available on all platforms. But the latter still has its uses, so I'm allowing metalevel breaches, but introducing the -Xlog-runtime-evals to log them.

upd. We no longer do that. In case of a runaway splice inside a reify, one will get a static error. Why? Unfortunately, the cute idea of transparently converting between static and dynamic splices has failed. 1) Runtime eval that services dynamic splices requires scala-compiler.jar, which might not be on library classpath 2) Runtime eval incurs a severe performance penalty, so it'd better to be explicit about it

As we can see, the only problem is the fact that lhs'es of splice can be code blocks that can capture variables from the outside. Code inside the lhs of an splice is not reified, while the code from the enclosing reify is.

Hence some bindings become cross-stage, which is not bad per se (in fact, some cross-stage bindings have sane semantics, as in the example above). However this affects freevars, since they are delicate inter-dimensional beings that refer to both current and next planes of existence. When splicing tears the fabric of the reality apart, some freevars have to go single-dimensional to retain their confidence.

Example 2. Consider the following snippet:

reify { val x = 2 reify{x}.splice }

Since the result of the inner reify is wrapped in a splice, it won't be reified together with the other parts of the outer reify, but will be inserted into that result verbatim.

The inner reify produces an Expr[Int] that wraps Ident(freeVar("x", IntTpe, x)). However the freevar the reification points to will vanish when the compiler processes the outer reify. That's why we need to replace that freevar with a regular symbol that will point to reified x.

Example 3. Consider the following fragment:

reify { val x = 2 val y = reify{x} y.splice }

In this case the inner reify doesn't appear next to splice, so it will be reified together with x. This means that no special processing is needed here.

Example 4. Consider the following fragment:

reify { val x = 2 { val y = 2 val z = reify{reify{x + y}} z.splice }.splice }

The reasoning from Example 2 still holds here - we do need to inline the freevar that refers to x. However, we must not touch anything inside the splice'd block, because it's not getting reified.

Map that stores freshly generated names linked to the corresponding names in the reified tree. This information is used to reify names created by calls to freshTermName and freshTypeName.

An (unreified) path that refers to definition with given fully qualified name

For reifee and other reification parameters, generate a tree of the form

{
  val $u: universe.type = <[ universe ]>
  val $m: $u.Mirror = <[ mirror ]>
  $u.Expr[T](rtree)       // if data is a Tree
  $u.TypeTag[T](rtree)    // if data is a Type
}

where

• universe is the tree that represents the universe the result will be bound to.
• mirror is the tree that represents the mirror the result will be initially bound to.
• rtree is code that generates reifee at runtime.
• T is the type that corresponds to data.

This is not a method, but a value to indicate the fact that Reifier instances are a one-off.

Keeps track of whether this reification contains abstract type parameters

Reifies any supported value. For internal use only, use reified instead.

Reifies list filling all the valid holeMap.

Reification of non-trivial list is done in two steps:

1. split the list into groups where every placeholder is always put in a group of its own and all subsequent non-holeMap are grouped together; element is considered to be a placeholder if it's in the domain of the fill function;

2. fold the groups into a sequence of lists added together with ++ using fill reification for holeMap and fallback reification for non-holeMap.

Example:

reifyHighRankList(lst) { // first we define patterns that extract high-rank holeMap (currently ..) case Placeholder(IterableType(_, _)) => tree } { // in the end we define how single elements are reified, typically with default reify call reify(_) }

Sample execution of previous concrete list reifier:

> val lst = List(foo, bar, qq$f3948f9s$1) > reifyHighRankList(lst) { ... } { ... } q"List($foo, $bar) ++ ${holeMap(qq$f3948f9s$1).tree}"

Reifies arbitrary list filling ..$x and ...$y holeMap when they are put in the correct position. Falls back to regular reification for zero rank elements.

Reify a case object defined in Mirror

Reify a reference to a symbol

Reify a tree. For internal use only, use reified instead.

Reify a type. For internal use only, use reified instead.

Rolls back certain changes that were introduced during typechecking of the reifee.

These include: * Undoing macro expansions * Replacing type trees with TypeTree(tpe) * Reassembling CompoundTypeTrees into reifiable form * Transforming Modifiers.annotations into Symbol.annotations * Transforming Annotated annotations into AnnotatedType annotations * Transforming Annotated(annot, expr) into Typed(expr, TypeTree(Annotated(annot, _)) * Non-idempotencies of the typechecker: https://github.com/scala/bug/issues/5464

Encapsulates reifier state

When untangling reifier symbol tables from the reifier itself, I discovered that encoding of a symbol table (e.g. producing corresponding reificode) might cause subsequent reification (e.g. when filling in signatures and annotations for syms).

This is a mess in the face of nested reifications, splices and inlining of thereof, so I made SymbolTable immutable, which brought a significant amount of confidence.

However that wasn't enough. Sure, symbol table became immutable, but the reifier still needed to mutate its symtab field during reification. This caused nasty desyncs between the table being encoded and the table of the underlying reifier, so I decided to encapsulate the entire state here, so that encoding can backup the state before it starts and restore it after it completes.

Symbol table of the reifee.

Keeps track of auxiliary symbols that are necessary for this reification session. These include: 1) Free vars (terms, types and existentials), 2) Non-locatable symbols (sometimes, e.g. for RefinedTypes, we need to reify these; to do that we create their copies in the reificode) 3) Non-locatable symbols that are referred by #1, #2 and #3

Exposes three main methods: 1) syms that lists symbols belonging to the table, 2) symXXX family of methods that provide information about the symbols in the table, 3) encode that renders the table into a list of trees (recursively populating #3 and setting up initialization code for #1, #2 and #3)

An (unreified) path that refers to term definition with given fully qualified name

Wraps expressions into: a block which starts with a sequence of vals that correspond to fresh names that has to be created at evaluation of the quasiquote and ends with reified tree:

{ val name$1: universe.TermName = universe.build.freshTermName(prefix1) ... val name$N: universe.TermName = universe.build.freshTermName(prefixN) tree }

Wraps patterns into: a call into anonymous class' unapply method required by unapply macro expansion:

new { def unapply(tree) = tree match { case pattern if guard => Some(result) case _ => None } }.unapply(<unapply-selector>)

where pattern corresponds to reified tree and guard represents conjunction of equalities which check that pairs of names in nameMap.values are equal between each other.