Open dbarvitsky opened 10 months ago
I attempted changing the predicate to something less strict. ~This does not solve the problem, actually makes it worse by causing the double-expansion of the @enum
macro and later failing the compilation. There probably is more to it than just wrapping the right tree.~
Edit: the double-invocation of the macro was my fault, not caused by the original issue
I thought I was recently (a few days ago maybe) reading about this issue, where macro annotation doesn't run so typechecking failure also fails scaladoc. I don't think I dreamt it, but I couldn't find the conversation when I looked earlier. If anyone knows what I'm talking about, a link would be much appreciated.
@som-snytt, thanks for looking into this. I poked around in the issues, nothing familiar. In my case the macros seem to run though (confirmed by tracing / setting breakpoints).
Reproduction steps
Scala version: 2.13.11
Hit this while migrating one of the company's internal tools to 2.13.11 from 2.11.x (asking for trouble, I know).
The unit test to reproduce the problem:
Problem
Both
@constants
and@enum
are no-op whitebox macros returningannottees.head
(they used to do some tree manipulation, but I created a no-op version for the test). I was able (I think) to track the problem down toMacroAnnotationNamers.expandMacroAnnotation
:For first macro expansion (
@constants
):derivedTrees
is a single-element array containing the expanded tree (as expected)stat
is theDocDef
with correct comment, as expectedsym
is theSymbols$ModuleSymbol
that is exactly the same asderivedTrees.head.symbol
rewrapAfterTransform
is called withtransformed = me = derivedTrees.head
and the first case wraps the tree as expectedFor the second macro expansion (
@enum
):derivedTrees
is likewise a single-element array containing the expanded treestat
is theDocDSef
with correct comment, as beforesym
is theSymbols$ClassSymbol
ofclass Nested
, thederivedTrees.head.symbol
is alsoSymbols$ClassSymbol
ofclass Nested
but they are for some reason different (with respect to equality). They both correspond to the same_rawname
and have the same_rawowner
, and only seem to be different byrawatt
andsymbolinfos
.rewrapAfterTransform
is called withtransformed = me = List.empty()
and the third case returns the empty listWhat I think is happening here is predicate
_.symbol == sym
inderivedTree.partition(_.symbol == sym)
returns false, and the expanded tree ends up inothers
as opposed tome
. It looks wrong in this case, since the bothsym
andderivedTrees.head.symbol
actually reference to the sameclass Nested
, just before and after expansion.Perhaps the predicate should be relaxed somehow? Admittedly, I am out of my depth here and couldn't figure out where the symbols come from during the expansion, or why they end up being different in nested case. So I apologize in advance for confusion.
Additional observations / variance
The problem does not reproduce if
Nested
is not nested inContainer
. Top-level macro applications seem to be working as expected:The problem reproduces even if
Container
does not have@constants
macro annotation. E.g. the following still fails in the same way.Thank you! Happy to provide more context / assistance / testing.