-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Spurious "Cyclic macro dependencies" error with pipelining turned on #20119
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
Comments
from debugging so far it seems like a problem in macro splicing, suddenly there are far more "missing class" suspensions that do not appear without pipelining. |
This is looking closer to a problem of build configuration - i.e. if a macro in project b uses a class in project a, then pipelining will need to be disabled on project a, but the error message is obscure. E.g. in DFiant it looks like there is a class from the Edit: it is still classed as a bug, because the error being reported is incorrect, it should be another error instead |
So the situation is basically that `DFiant` and `html.scala` projects do not work "out of the box" with pipelining, and will need to tune their builds if they want some pipelining. However, the compiler reports an error that is not helpful to the user, so in this PR we report a better one. Previously, it was assumed that a missing class (that is valid in current run) during macro evaluation was due to the symbol being defined in the same project. If this condition is met, then compilation is suspended. This assumption breaks when the symbol comes from the classpath, but without a corresponding class file, leading a situation where the same file is always suspended, until it is the only one left, leading to the "cyclic macro dependencies" error. In this case we should assume that the class file will never become available because class path entries are supposed to be immutable. Therefore we should not suspend in this case. This commit therefore detects this situation. Instead of suspending the unit, the compiler aborts the macro expansion, reporting an error that the user will have to deal with - likely by changing the build definition/ In the end, users will see a more actionable error. Note that sbt already automatically disables pipelining on projects that define macros, but this is not useful if the macro itself depends on upstream projects that do not define macros. This is probably a hard problem to detect automatically - so this is good compromise. We also fix `-Xprint-suspension`, which appeared to swallow a lot of diagnostic information. Also make `-Yno-suspended-units` behave better. fixes #20119
Uh oh!
There was an error while loading. Please reload this page.
Compiler version
3.5.0-RC1-bin-20240404-a7f00e2-NIGHTLY
Minimized code
both these projects exhibit the behaviour:
https://github.com/DFiantHDL/DFiant/tree/pipeline
https://github.com/atry/html.scala/tree/v3.0.3
Add these lines to build.sbt
Output
from command
html/Test/compile
in atry/html.scalafrom command
core/compile
in DFiantHDL/DFiantboth do not appear if pipelining is turned off.
Expectation
compile as normal
The text was updated successfully, but these errors were encountered: