-
Notifications
You must be signed in to change notification settings - Fork 931
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.13.11 regression: incremental compiler misses when macro expansion references another source #2560
Comments
Do you know why existing scripted tests for macros didn't catch the regression? |
eed3si9n
added a commit
to eed3si9n/sbt
that referenced
this issue
Apr 18, 2016
Unlike other scripted macro tests, the call site of this macro is `Provider.tree(0)`, which does not introduce internal member reference. Instead the macro itself calls `Bar.bar(0)`. Due to sbt#2560, the expanded tree is not traversed, and thus the reference to `Bar` is not caught during incremental compilation.
eed3si9n
added a commit
to eed3si9n/sbt
that referenced
this issue
Apr 18, 2016
traverse(tree: Tree) used to call super.traverse(tree) at the end. sbt/sbt@0f61629 brought the traversing call to inside of the pattern matching. For the case of MacroExpansionOf(original), it amounts to not traveling the macro-expanded code. See sbt/src/sbt-test/source-dependencies/macro-nonarg-dep for the repro.
@gkossakowski See the new repro in #2563. The existing scripted tests didn't catch this because the macro is too simple, and it doesn't introduce new member ref beyond the original tree. |
eed3si9n
added a commit
to eed3si9n/sbt
that referenced
this issue
Apr 18, 2016
Unlike other scripted macro tests, the call site of this macro is `Provider.tree(0)`, which does not introduce internal member reference. Instead the macro itself calls `Bar.bar(0)`. Due to sbt#2560, the expanded tree is not traversed, and thus the reference to `Bar` is not caught during incremental compilation.
eed3si9n
added a commit
to eed3si9n/sbt
that referenced
this issue
Apr 18, 2016
traverse(tree: Tree) used to call super.traverse(tree) at the end. sbt/sbt@0f61629 brought the traversing call to inside of the pattern matching. For the case of MacroExpansionOf(original), it amounts to not traveling the macro-expanded code. See sbt/src/sbt-test/source-dependencies/macro-nonarg-dep for the repro.
eed3si9n
added a commit
that referenced
this issue
Apr 19, 2016
Fixes incremental compiler missing member ref from macro expansion #2560
eed3si9n
added a commit
to eed3si9n/scala
that referenced
this issue
May 14, 2019
traverse(tree: Tree) used to call super.traverse(tree) at the end. sbt/sbt@0f61629 brought the traversing call to inside of the pattern matching. For the case of MacroExpansionOf(original), it amounts to not traveling the macro-expanded code. See sbt/src/sbt-test/source-dependencies/macro-nonarg-dep for the repro.
lrytz
pushed a commit
to lrytz/scala
that referenced
this issue
Nov 5, 2019
traverse(tree: Tree) used to call super.traverse(tree) at the end. sbt/sbt@0f61629 brought the traversing call to inside of the pattern matching. For the case of MacroExpansionOf(original), it amounts to not traveling the macro-expanded code. See sbt/src/sbt-test/source-dependencies/macro-nonarg-dep for the repro. Rewritten from sbt/zinc@acf4fac
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
steps
A.scala
references another sourceB.scala
.B.scala
.problem
A.scala
doesn't get compiled.expectation
A.scala
gets compiled.notes
This can be confirmed when "member reference internal dependencies" doesn't contain the entry from
A.scala
toB.scala
.This was caused by 0f61629:
This won't traverse into an
Apply
tree, for instance if it hasMacroExpansionAttachment
. The fix is to callsuper.traverse(tree)
forMacroExpansionOf
case as well.The text was updated successfully, but these errors were encountered: