[Proof of Concept] Code generation via rewriting errors in macro annotations #16545
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
smarter
force-pushed
the
macro-codegen
branch
from
a1c63e7 to
53716bf
Compare
smarter
commented
Dec 16, 2022
| case _ => | ||
| report.error(s"Replace the underline code by:\n$expectedBody", rhs.pos) | ||
| case _ => | ||
| report.error("FIXME: Passing -Yretain-trees is currently needed for this macro to work") |
There was a problem hiding this comment.
@nicolasstucki I'm surprised -Yretain-trees is needed since I'm accessing the tree of a symbol defined in the class being annotated, so the tree is accessible via traversing the tree argument of the macro annotation transform method, but it would be more convenient if I could access it through Symbol#tree too.
nicolasstucki
force-pushed
the
macro-codegen
branch
from
53716bf to
9ad1732
Compare
|
@smarter I rebased and solved the conflicts. I will have a look at the implementation and maybe add some changes. |
smarter
commented
Jan 3, 2023
Comment on lines
22
to
31
| cls.declaredMethod(withParam).find(o => | ||
| val paramss = o.paramSymss | ||
| paramss.size == 1 && paramss(0).size == 1 | ||
| cdef.body.find(stat => | ||
| val paramss = stat.symbol.paramSymss | ||
| stat.symbol.name == withParam | ||
| && paramss.size == 1 && paramss(0).size == 1 |
There was a problem hiding this comment.
@nicolasstucki I understand that we can look into the input tree directly, but in my opinion we should also be able to use Symbol#tree for this usecase, unless there is something that prevents us from using it?
…tations This commit prototypes the proposal in https://contributors.scala-lang.org/t/scala-3-macro-annotations-and-code-generation/6035 to use a macro annotation to do code generation. Since the -rewrite mechanism isn't currently accessible to macros, we just print an error indicating what part of the source code needs to be rewritten. We implement support for a subset of `@data`: only the `withField` methods are added (note that equals/hashCode/toString wouldn't need to be code-generated since they are already defined in `AnyRef`, so a macro annotation can override them as demonstrated in the existing `tests/run-macros/annot-mod-class-data` test). This is only one possible path forward. Alternatively, we could recommend using scalafix for this usecase, and then the compiler itself wouldn't have to grow code generation abilities, but libraries defining macro annotation might not like to be tied to an external tool.
We can't just pattern match on it because of scala#16543.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR prototypes the proposal in
https://contributors.scala-lang.org/t/scala-3-macro-annotations-and-code-generation/6035
to use a macro annotation to do code generation. Since the -rewrite mechanism
isn't currently accessible to macros, this proof of concept just prints an error indicating what
part of the source code needs to be rewritten.
We implement support for a subset of
@data: only thewithFieldmethods areadded (note that equals/hashCode/toString wouldn't need to be code-generated
since they are already defined in
AnyRef, so a macro annotation can overridethem as demonstrated in the existing
tests/run-macros/annot-mod-class-datatest).
This is only one possible path forward. Alternatively, we could recommend using
scalafix for this usecase, and then the compiler itself wouldn't have to grow
code generation abilities, but libraries defining macro annotation might not
like to be tied to an external tool.