Reduce number of Symbol.tree
dependencies in macros.
#525
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.
Symbol.tree
usage is considered as an anti-pattern, because the tree is not guaranteed to exist.Right now the only use case, that cannot be resolved without trees, is the annotation of base classes, eg.
class X extends Y @MyAnnot
.This change was mostly motivated by the bug in the compiler I was not able to reproduce and minimise yet - under some conditions case class parameters can be generated before inlining (macros expansion) finishes. This leads to creation of param accessors that are not correctly handled in quotes. The call to
CollectAnnotations.fromDeclarations
with a parameter accessor would not be correctly handled. When executionSymbol.tree
compiler would see that symbol has noMethod
flag so it assumes it as aValDef
, however, actually the tree of the parameter accessor is aDefDef
which leads to MatchError when interpreting macros. Stack trace from this kind of errors can be found below