-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Incorrect children queried before class was discovered
error when typeCheckErrors is used
#18484
Comments
…call Sometimes, a macro or Mirror can be called/generated for a type that may have not had its children registered by natural typechecking procedures of the compiler. This meant that, in those cases, the Mirror could not have been generated correctly, and macro could not obtain the children of the class. This was partially fixed in a previous PR by introducing a separate procedure for querying children, outside of the regular typechecking procedure. However, they was only queried in the owner symbol or in the companion class, when non-enum sealed classes specifically, can appear anywhere in the file. This commit aims to rectify this by searching for any class that appears in the same file as the sealed type.
…call Sometimes, a macro or Mirror can be called/generated for a type that may have not had its children registered by natural typechecking procedures of the compiler. This meant that, in those cases, the Mirror could not have been generated correctly, and macro could not obtain the children of the class. This was partially fixed in a previous PR by introducing a separate procedure for querying children, outside of the regular typechecking procedure. However, they was only queried in the owner symbol or in the companion class, when non-enum sealed classes specifically, can appear anywhere in the file. This commit aims to rectify this by searching for any class that appears in the same file as the sealed type.
This issue unfortunately will not be fixed. The limitation mentioned in the error message is clear and expected. Apparently these kinds of symbol loading issues were a frequent problem in scala 2, which is why this limitation was chosen for non-standard symbol loading contexts (like the macro entry being in the same file). An experimental fix was prepared with #18484, however in addition to it being not performant, it would force us to spend more time later on related issues (as the limitation would then be made inconsistent). A workaround fix here is to move the macro call outside of the enum definition. |
Compiler version
3.3.0, main (8c311a0)
Minimized code
macro.scala
test.scala
Output
Expectation
Code should compile, as it does when either the code inside typeCheckErrors is extracted outside of that method.
Original minimization by @MateuszKubuszok with usage context: here
The text was updated successfully, but these errors were encountered: