Skip to content

Fix macro dependency tracking for this #18452

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

Closed
wants to merge 1 commit into from

Conversation

nicolasstucki
Copy link
Contributor

The symbols of trees do not have enough information to determine the full dependencies. For example, if we have an Ident we need to look at its type to figure out which is the this prefix on which it is defined.

Fix #18434

@nicolasstucki nicolasstucki marked this pull request as ready for review August 24, 2023 18:59
@nicolasstucki nicolasstucki requested a review from smarter August 24, 2023 18:59
@@ -1062,15 +1062,23 @@ class Inliner(val call: tpd.Tree)(using Context):
* This corresponds to the symbols that will need to be interpreted.
*/
private def macroDependencies(tree: Tree)(using Context) =
val typeAccumulator = new TypeAccumulator[List[Symbol]] {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's hard to figure out if this is good enough because it's hard to know which trees are valid here. I think it'd be much clearer if we combined this logic and the checks from checkIfValidStaticCall in the same traversal, so we'd know exactly which tree shape we need to handle.

By the way, checkIfValidStaticCall is flawed because of local imports:

object Inline extends Macro {
  val x: Macro = ???
  import x._
  inline def callMacro(): Int =
    ${ impl() }
}

@smarter smarter assigned nicolasstucki and unassigned smarter Aug 24, 2023
The symbols of trees do not have enough information to determine the
full dependencies. For example, if we have an `Ident` we need to look at
its type to figure out which is the `this` prefix on which it is defined.

Fix scala#18434
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Another ClassNotFoundException when evaluating inline def which calls a macro defined in a super-class
2 participants