-
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
CyclicReference exception, thrown only during incremental compilation #16673
Comments
A way to reproduce directly:
|
This is a fairly serious problem. It's because we read the complete parent constructors when unpickling. By contrast, when type-checking sources, we skip the parent constructor arguments in Namer as long as they are not needed to determine the type of the result of a constructor. |
I think this might be a source of instability in other incremental compilation scenarios as well. |
Avoid reading the arguments of parent constructors unless someone forces them. We don't need them to determine the parent types of the class to which the template belongs. This makes TreeUnpickler as lazy as Namer in this respect and therefore avoids CyclicReferences during unpickling. Fixes scala#16673
Avoid reading the arguments of parent constructors unless someone forces them. We don't need them to determine the parent types of the class to which the template belongs. This makes TreeUnpickler as lazy as Namer in this respect and therefore avoids CyclicReferences during unpickling. Fixes scala#16673
@marcinzh Thanks a lot for minimizing the code to illustrate the bug so concisely! |
Avoid reading the arguments of parent constructors unless someone forces them. We don't need them to determine the parent types of the class to which the template belongs. This makes TreeUnpickler as lazy as Namer in this respect and therefore avoids CyclicReferences during unpickling. Fixes #16673
Avoid reading the arguments of parent constructors unless someone forces them. We don't need them to determine the parent types of the class to which the template belongs. This makes TreeUnpickler as lazy as Namer in this respect and therefore avoids CyclicReferences during unpickling. Fixes scala#16673
Compiler version
3.2.1
3.2.2-RC2
Minimized code
Important: We need 2 separete files, or else the error won't happen.
Foo.scala:
FooStub.scala:
Output
Clean compile succeeds.
To trigger the error, do the following:
~compile
in sbtFooStub
source: add or remove 1 digit frombar
Again, clean recompile succeeds. Until another minor change of source.
After adding suggested
-Ydebug-unpickling
and-explain
options, got this:Also, this thing showed up once:
The text was updated successfully, but these errors were encountered: