处理宏注释时无法访问父级成员 [英] Can't access Parent's Members while dealing with Macro Annotations

问题描述

我被以下内容阻止(宏注释)情况.假设我有一个名为 @factory 的注释，它旨在为相应的伴生对象中的注释特征生成 apply 方法.例如，给定 trait A:

I am kind of blocked with the following (macro annotation) situation. Suppose I have an annotation called @factory which aims to generate an apply method for the annotated trait in the corresponding companion object. For instance, given the trait A:

@factory
trait A {
  val a1: Int
}

预期生成的代码如下:

object A extends Factory[A] {
  def apply(_a1: Int) = new A {
    val a1 = _a1
  }
}

现在假设我们有一个继承自 A 的特征 B:

Now suppose we have a trait B which inherits from A:

@factory
trait B extends A {
  val b1: String
}

应该生成:

object B extends Factory[B] {
  def apply(_a1: Int, _b1: String) = new B {
    val a1 = _a1
    val b1 = _b1
  }
}

在后一种情况下，我需要知道 A 中存在哪些属性，但我不知道如何获取有关它们的任何信息.在处理宏注释时，我只能访问 B trait AST(作为 ClassDef).尽管它的 template 包含对父项的引用(如 TypeTrees)，tpe 和 symbol 字段都是空的.

In the latter case, I need to know which are the attributes existing at A, but I don't know how to get any information about them. While dealing with macro annotations I have only access to the B trait AST (as a ClassDef). Although its template contains references to the parents (as TypeTrees), both fields tpe and symbol are empty.

如果我能访问 A AST，那就太好了.但是，我认为这是不可行的.因此，任何符号或类型(指向父类型或当前类型)就足够了.

It would be great for me to get access to the A AST. However, I think that's not feasible. Therefore, any symbol or type (pointing either the parent or the current type) would be good enough.

如果你想看更多的实现细节，我已经把项目上传到了https://github.com/jesuslopez-gonzalez/cool-factory.它可以为本地值生成apply.

If you want to see more implementation details, I have uploaded the project to https://github.com/jesuslopez-gonzalez/cool-factory. It can generate the apply for the local values.

推荐答案

进入宏注释参数的树是有意无类型的.但是运行 c.typeCheck(q"(??? : <tree thatpresent the parent>)").tpe 将提供丢失的信息.不要忘记在类型检查之前复制那棵树，因为 c.typeCheck 会在原地改变树，这可能是不可取的.

Trees that go into macro annotation arguments are purposefully untyped. However running c.typeCheck(q"(??? : <tree that represents the parent>)").tpe will provide the missing information. Don't forget to duplicate that tree before typechecking, because c.typeCheck mutates the tree in place, which might be undesireable.

如果 parent 和 child 都声明在同一个 non-toplevel scope 中，就会出现 typeCheck 看不到 parent 的问题，因为宏注解中的 c.typeCheck 是在父词法范围内执行的，这样注解就不会出现看不到半成品的瞄准镜.这里也有类似的报道:https://github.com/aztek/scala-workflow/issues/2#issuecomment-23947943.

In case when both parent and child are declared in the same non-toplevel scope, there will be a problem of typeCheck not seeing the parent, as c.typeCheck's in macro annotations are performed in parent lexical scope, so that annotations don't get to see half-constructed scopes. Something similar has been reported here: https://github.com/aztek/scala-workflow/issues/2#issuecomment-23947943.

从类型检查中排除当前范围的决定不是最终决定.本周我将更多地思考宏注释应该如何与封闭的作用域交互，并且可能会更改它以执行您希望它执行的操作.我会立即进行更改，但我需要确保该更改不会引起任何疯狂的行为.

The decision to exclude current scope from typechecking is not a final one. This week I'll be thinking a bit more about how macro annotations should interact with enclosing scopes, and will probably change it to do what you would like it to do. I'd do the change right now, but I need to make sure there won't be any insane behaviour arising from that change.

这篇关于处理宏注释时无法访问父级成员的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！