Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | deprecates macro def return type inference | Eugene Burmako | 2013-12-10 | 1 | -1/+1 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the new focus on quasiquotes in macro implementations, we now have to change the way how inference of macro def return types works. Previously, if the return type of a macro def wasn’t specified, we looked into the signature of its macro impl, took its return type (which could only be c.Expr[T]) and then assigned T to be the return type of the macro def. We also had a convenient special case which inferred Any in case when the body of the macro impl wasn’t an expr. That avoided reporting spurious errors if the macro impl had its body typed incorrectly (because in that case we would report a def/impl signature mismatch anyway) and also provided a convenience by letting macro impls end with `???`. However now we also allow macro impls to return c.Tree, which means that we are no longer able to do any meaningful type inference, because c.Tree could correspond to tree of any type. Unfortunately, when coupled with the type inference special case described above, this means that the users who migrate from exprs to quasiquotes are going to face an unpleasant surprise. If they haven’t provided explicit return types for their macro defs, those types are going to be silently inferred as `Any`! This commit plugs this loophole by prohibiting type inference from non-expr return types of macro impls (not counting Nothing). Moreover, it also deprecates c.Expr[T] => T inference in order to avoid confusion when switching between exprs and quasiquotes. | ||||
* | blackbox and whitebox macros | Eugene Burmako | 2013-11-12 | 1 | -3/+3 |
| | | | | | | | | | | | | | | | | | | This is the first commit in the series. This commit only: 1) Splits Context into BlackboxContext and WhiteboxContext 2) Splits Macro into BlackboxMacro and WhiteboxMacro 3) Introduces the isBundle property in the macro impl binding Here we just teach the compiler that macros can now be blackbox and whitebox, without actually imposing any restrictions on blackbox macros. These restrictions will come in subsequent commits. For description and documentation of the blackbox/whitebox separation see the official macro guide at the scaladoc website: http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html Some infrastructure work to make evolving macros easier: compile partest-extras with quick so they can use latest library/reflect/... | ||||
* | changes some manual tree constructions in macro tests to quasiquotes | Eugene Burmako | 2013-10-18 | 1 | -2/+2 |
| | |||||
* | deprecates raw tree manipulation facilities in macros.Context | Eugene Burmako | 2013-10-18 | 1 | -2/+2 |
| | |||||
* | SI-5940 impls are no longer in macro def pickles | Eugene Burmako | 2012-08-13 | 1 | -0/+41 |
The first officially released version of macros persisted macro def -> impl bindings across compilation runs using a neat trick. The right-hand side of macro definition (which contains a reference to an impl) was typechecked and then put verbatim into an annotation on macro definition. This solution is very simple, but unfortunately it's also lacking. If we use it then signatures of macro defs become transitively dependent on scala-reflect.jar (because they refer to macro impls, and macro impls refer to scala.reflect.macros.Context defined in scala-reflect.jar). More details can be found in https://issues.scala-lang.org/browse/SI-5940. Therefore we have to avoid putting macro impls into binding pickles and come up with our own serialization format. Situation is further complicated by the fact that it's not enough to just pickle impl's class and method names, because macro expansion needs knowledge about the shape of impl's signature (which we can't pickle). Hence we precompute necessary stuff (e.g. the layout of type parameters) when compiling macro defs. |