Illegal meta-rules probably shouldn't compile

[lihaoyi]

scala> class C(val input: ParserInput) extends Parser{
     |  def id(r: Rule0) = r
     |  def MyRule = rule( "omg" )
     |  def MyRule2 = rule( "wtf" ~ id(MyRule) )
     | }
defined class C

If we're going to dedicate paragraphs of text and code-snippets to say how illegal this code is, is there any way to make it not-compile? If we can't make it work properly maybe we can at least make it not compile

Note that a related parser does not compile, but probably for the wrong reasons

scala> class C(val input: ParserInput) extends Parser{
     | def id(r: Rule0) = r
     | def MyRule = rule( "omg" ~ id("wtf" ~ "bbq") )
     | }
<console>:12: error: Calls to `~` must be inside `rule` macro
       def MyRule = rule( "omg" ~ id("wtf" ~ "bbq") )
                                           ^
<console>:12: error: Calls to `str` must be inside `rule` macro
       def MyRule = rule( "omg" ~ id("wtf" ~ "bbq") )
                                     ^
<console>:12: error: Calls to `str` must be inside `rule` macro
       def MyRule = rule( "omg" ~ id("wtf" ~ "bbq") )

[sirthias]

The question is how we can distinguish between the in principle legal (#116):

def foo = rule(bar(baz))
def bar(r: => Rule0) = r
def baz = rule(...)

and the definitely illegal

def foo = rule(bar(baz))
def bar(r: Rule0) = r
def baz = rule(...)

On the type level there is no difference, so we'd have to catch it in one of the macro expansions.
In baz we can't, because that is a legal rule in itself.
So we have to catch it in the expansion of the foo rule macro by realizing that an expression evaluating to RuleX is passed as argument to a call where the respective parameter is not call-by-name. However, at the call site of bar there is no difference between passing a normal and passing a call-by-name argument.
We need to be able to look at the signature of bar at the call site for bar, which is (AFAIK) impossible with the current macro infrastructure and the per-rule macro approach we currently apply.

So, it appears to me that we won't be able to clear this ticket before having cleared #118.