Skip to content

Conversation

jchyb
Copy link
Contributor

@jchyb jchyb commented Sep 3, 2025

Fixes #21176
The scaladoc for the defTree method in Symbols.scala states: "The tree defining the symbol at pickler time ...", but that was never really true.
Previously, since the setDefTree method was used in Typer, in any retyping procedure those methods would be called again, with the main example being erasure, where we would lose parts of type information from those trees. Usually this was not an issue, since they weren't used after Erasure.
However, the suspend mechanism used when compiling macros with calls to them can cause the macro tree to go through
erasure, have their defTrees updated there and then used for earlier phases, with the problematic phase here being the init-checker, which uses defTree calls extensively.
In the issue minimisation, init-checker was expecting a MethodType (due to the missing TypeApply there after erasure), and instead got a PolyType, causing a crash.

Coincidentally in the past we would sometimes also get issues about .tree method in Quotes returning unexpected stuff due to the same issue, so this should also help there (this is why the test case for #22584 was changed, val symbol returning a ValDef makes more sense anyway).

In the first commit we also reset the TyperState after suspension, to avoid any unfulfilled constraints raised in Ycheck, as mentioned in the same issue ticket (although the causes ended up being separate) .

This is to avaoid unfulfilled constraints when
going through -Ycheck later.
The scaladoc for the defTree method in Symbol states: "The tree defining
the symbol at pickler time ...", but that was never really true.
Previously, since the setDefTree method was used in Typer, in any
retyping procedure those methods would be called again, with the main
example being erasure, where we would lose parts of type information from
those trees. Usually this was not an issue, since they weren't used after
Erasure.
However, the suspend mechanism used when compiling
macros with calls to them can cause the macro tree to go through
erasure, have their defTrees updated there, and then used for earlier
phases, with the problematic phase here being the init-checker, which
uses defTree calls extensively.
In the issue minimisation, init-checker was expecting a MethodType (due to the
missing TypeApply there), and instead got a PolyType, causing a crash.

Coincidentally in the past we would sometimes also get issues about
.tree method in Quotes returning unexpected stuff due to the same issue,
so this should also help there.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compiler fails in generic inline method that uses macro with 'safe-init'
2 participants