Scala 宏 : What is the difference between typed (aka typechecked) and untyped Trees

Question

我开始使用 Scala 宏，它们很棒，但我遇到了类型化(又名类型检查)和非类型化 Tree 之间的区别s。

例如，您不能拨打 c.eval出于某种原因使用类型检查树。我在 scala 宏文档中找不到关于这个“类型检查”的文档(我知道他们仍在努力，这可能是某天需要添加的东西)。
Tree 是什么意思进行类型检查？为什么它们如此不同以至于显然 c.eval 无法处理类型检查 Tree s(相反对我来说更有意义)。

我想这可能是编译器 101，但我没有上那门课:(
任何解释或指向文章/文档的指针将不胜感激!

Answer 1

理论部分

这是 scalac 的架构特性，一旦我们在 2.10 中的编译时/运行时反射中公开内部编译器数据结构，它就开始泄漏到公共(public) API 中。

粗略地说，scalac 的前端由一个解析器和一个类型器组成，它们都与树一起工作并产生树作为结果。然而，这些树的属性完全不同，这是因为解析器生成的树是无属性的(将它们的 symbol 字段设置为 NoSymbol 并将它们的 tpe 字段设置为 null )，而由解析器生成的树打字机被归因。

现在您可能想知道这有什么不同，因为它只是 symbol和 tpe ， 对？然而，在 scalac 中，它不仅仅如此。为了完成它的工作，typer 改变了它正在处理的 AST 的结构，破坏了一些原始树并产生了一些合成树。不幸的是，有时这些转换是不可逆的，这意味着如果对树进行类型检查，然后删除所有分配的属性，则生成的树将不再有意义( https://issues.scala-lang.org/browse/SI-5464 )。

好吧，但是为什么要删除(或用 Scalac 的说法，重置，如 resetLocalAttrs 或 resetAllAttrs )类型检查树的属性？嗯，这种必要性源于另一个实现细节 - 符号及其所有者链。就在几天前，我在 Scala-internals 上写了一些关于它的细节:https://groups.google.com/d/msg/scala-internals/rIyJ4yHdPDU/qS-7DreEbCwJ ，但简而言之，您不能在某些词法上下文中对树进行类型检查，然后简单地在不同的词法上下文中使用它(这正是 c.eval 所必需的)。

因此，总结一下 scalac 树管理的最新技术:

无类型树(也称为解析器树或无属性树)在观察上不同于类型树(也称为类型树、类型检查树或属性树)

这两种树风格之间有两个主要区别:a) 类型树具有由类型检查器设置的符号和类型，b) 类型树具有稍微不同的形状。

通常，如果某些编译器 API 使用树，则无类型树和类型树都可以。但是，在某些情况下(我在上面概述了其中一种情况)，只有无类型或只有类型的树才是合适的。

可以通过调用 Context.typecheck 从无类型树转到有类型树。 (编译时反射)或 ToolBox.typecheck (运行时反射)，但通过 resetLocalAttrs 从类型树返回到非类型树或 resetAllAttrs目前不可靠，因为 https://issues.scala-lang.org/browse/SI-5464 .

因此，如您所见，我们的树非常反复无常，这给 Scala 中的元编程带来了极大的复杂性。

然而，好消息是，这种复杂性并不是由源自编译器 101 的一些根本原因决定的。所有的复杂性都是偶然的，我们计划逐步消除它，直到它全部消失。 https://groups.google.com/forum/#!topic/scala-internals/TtCTPlj_qcQ (也在几天前发布)是朝着这个方向迈出的第一步。请继续关注今年也可能到货的其他好东西!

实用部分

在通过详细说明所有细节并暗指无效时的神秘案例将您彻底吓倒之后，我想指出通常人们在使用宏时不需要了解这种东西。通常，无类型树(手动构造的 AST、准引号)和类型树(宏参数)都可以正常工作。

在某些情况下，当 scalac 想要一种特定的树味时，它会告诉你 c.eval或者有时会在您的脸上崩溃(RefChecks、LambdaLift 和 GenICode 崩溃是在宏扩展期间树混淆的重要指标 - 在这些情况下使用 resetLocalAttrs，如 https://groups.google.com/forum/#!msg/scala-internals/rIyJ4yHdPDU/qS-7DreEbCwJ 中所述)。解决这个问题是我的首要任务，我现在正在努力。修复程序可能会使其成为 2.11.0，并且这个答案很快就会过时:)