8

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
}

the expected code to be generated is the following one:

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

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

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

which is supposed to generate:

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

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.

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.

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.

neutropolis
  • 1,884
  • 15
  • 34
  • Trees that go into macro annotation arguments are purposefully untyped. However, I think, running `c.typeCheck(q"(???: )").tpe` might provide the missing information. – Eugene Burmako Oct 15 '13 at 14:38
  • @EugeneBurmakoI had already tried that this morning, but it raised an error (not sure right now, but I think it said that type tree wasn't an expression). Anyway, I'll go further with `typeCheck` tomorrow. By the way, while I was analyzing the macros `Context` API, I read "provide facilities for exploring the compiler's symbol table". What's the way to do so? Thanks! – neutropolis Oct 15 '13 at 15:10
  • Sure, that's because you probably did `c.typeCheck()`. c.typeCheck expects a term, so it fails if you give it a type. – Eugene Burmako Oct 15 '13 at 21:05
  • The facilities for exploring the symbol table are implemented in c.mirror. – Eugene Burmako Oct 15 '13 at 21:05
  • I didn't notice the `q` in your first comment. You were right, I was passing the raw type to `c.typeCHeck` instead. Finally, I have used an `asInstanceOf[A]` as input expression and the type is generated nicely. However, there's still one problem. I can't declare both parent and child together (like this https://github.com/jesuslopez-gonzalez/cool-factory/blob/master/src/test/scala/es/kathars/factory/test/TFactory.scala) because if I do so, `typeCheck` can't find the parent type. Anyway, please, add a response in order to mark it as correct. – neutropolis Oct 16 '13 at 07:23
  • Regarding the last problem I mentioned, could it be possible that it only arises when both child and parent belong to the same compilation unit? If that's true, I think I can circumvent the problem by using the whole AST extracted from `c.enclosingUnit`. – neutropolis Oct 16 '13 at 08:33
  • The problem is with them being declared in the same lexical scope, not compilation unit. See my answer below. – Eugene Burmako Oct 16 '13 at 09:02

1 Answers1

12

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.

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.

Eugene Burmako
  • 13,028
  • 1
  • 46
  • 59
  • Looking forward for your final decision. Could you please post it here at your earliest convenience? Many thanks! – neutropolis Oct 16 '13 at 09:46
  • I'm afraid I'll have to delay the answer until the next week. I gave it a shot today and faced some ugly complications that need more than one pair of eyes. If you're interested, please join the discussion at: https://github.com/aztek/scala-workflow/issues/2. – Eugene Burmako Oct 17 '13 at 17:21
  • @EugeneBurmako How has the “no access to the local scope” issue evolved? – Jean-Philippe Pellet Feb 16 '15 at 15:44
  • It hasn't, unfortunately. Somewhere around the time of this question, we in the Scala team have agreed that before proceeding with macro annotations, we need to get regular macros right. This is when scala.meta was born, and that's been consuming most of my dedication ever since. – Eugene Burmako Feb 16 '15 at 19:49