mention in readme that explicit return type is required
cvogt opened this issue · comments
Seem that if the return type is inferred to something more concrete than Tree, you end up with something like
value fooMacro is not a member of object FooMacros
Perhaps we can actually fix this.
Would you mind providing a minimal case, if you happen to have one handy.
import scala.language.experimental.macros
import scala.reflect.macros.whitebox.Context
object Defaults {
def apply[T]: AnyRef = macro DefaultsMacros.defaults[T]
}
@macrocompat.bundle
class DefaultsMacros( val c: Context ) {
import c.universe._
def defaults[T: c.WeakTypeTag] = { // requires exlicit : Tree return type
q"""new { def foo = "test" }"""
}
}this also seems not to work in 2.10. If I try to access foo I get AnyRef does not have this method error.
This is the same problem that @non was having the other day. The result types are mandatory.
@milessabin We create forwarders methods for methods returning Expr's and Tree's, perhaps it's possible to match on <:< Tree in this case?
We're running before typer, so I think not.
I think the only thing we can do here is document the requirement. We could warn/error for any method without an explicit result type I suppose, but that might be a bit noisy.
I'd suggest putting it into the code sample as I did above if documented.
If there could be error messages if you reference a method as a macro, but it doesn't have the right signature, that would be best.
Side-question: Any idea why I was not seeing whitebox behavior on 2.10, where I expected it to automatically downcast from AnyRef to my refinement, but it didn't?
All the examples in the README and the tests have explicit result types ... what else do you think should be added?
Unfortunately, we can't warn about usage, again because we're running before typer ... this is a purely syntactic transformation.
On the side-question: it should ... if you have a small standalone reproduction it would deserve a separate ticket.
re README: #66
Is a syntactic desugaring able to check if methods have explicit return types, i.e. able to complain if they don't?
side-question: will see what I can do
We could spot that a method doesn't have a return type, but we can say for sure that it's actually a macro method which should be transformed and have forwarders generated for it ... it's the specific form, including the result type which indicates that.
Fixed in #66 ...