fix: Fix incremental compilation of (some unquoted) macros #24171
Conversation
**Problem** sbt-deps phase runs after the Typer, but prior to the Inliner. This means that the Zinc won't be able to track the symbolic dependency from the use site to the generated code, unless the code exists as a form of quotation. This often results in under-compilation of the macro use sites. **Solution** 1. Move the sbt-deps phase after the Inliner, which expands the macros 2. Traverse the Inlined tree, and treat it like a normal code
eed3si9n
force-pushed
the
wip/incremental-compilation
branch
from
ebcfec5 to
dd58f75
Compare
|
The title of this PR is a bit misleading. It fixes one (important) issue with macro invalidation. It hardly fixes incremental compilation of macros as a whole. ;-) |
eed3si9n
changed the title
|
As @sjrd would probably mention given a chance - even with this you can still have a dependency on a symbol during the macro run that never makes it to the inlined tree, e.g. if you generate code based on presence of a symbol - which would only be fixed by instrumenting each symbol operation during typer/posttyper/inlining etc to record deps |
Note that we already have some infrastructure for doing instrumentation in any phase where it's appropriate rather than specifically sbt-deps, this should avoid the need for moving sbt-deps itself which is likely to break things as it fixes other things indeed: #18310 |
eed3si9n
force-pushed
the
wip/incremental-compilation
branch
from
1eb1817 to
dd58f75
Compare
6 participants
Fixes #23852
Accompanying blog post: incremental compilation of Scala 3
Problem
sbt-deps phase runs after the Typer, but prior to the Inliner. This means that the Zinc won't be able to track the symbolic dependency from the use site to the generated code, unless the code exists as a form of quotation.
This often results in under-compilation of the macro use sites.
Solution