-
Notifications
You must be signed in to change notification settings - Fork 279
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
TypeName subclasses can cause StackOverflowError in hashCode/equals in cyclic types #1737
Comments
As another idea for a potential fix, it seem incorrect that I see that the bounds are being used when the name is part of a class declarations, but conceptually, the declaration is using more than the classname. It is also the declaration of the type variables. Presumably there could/should be a different API for this purpose. That is, |
Thanks for the report. Did you want to try and send a PR with a fix? If not, someone will get to it when we have free time. |
I have hacked around this locally by adding a depth counter to equals. It's not exactly a problem I'm looking to revisit 😁 |
Describe the bug
When calling hashCode/equals on a TypeName with a cyclic definition, there can be a StackOverflowError
To Reproduce
I'm not 100% what type is causing the issue. However, reading the implementations of these functions, it's clear that they call into on another, with no guards for the cyclic case.
Expected behavior
These functions should not throw.
Additional context
hashCode is relatively easy to fix by ignoring potentially cyclic fields. However, equals is trickier.
Having solved a very similar problem in the JSCompiler typesystem, the solution was to implement equals as a visitor that traversed over the type-graph, accumulating state to detect cycles.
Here are the top few loops in the stacktrace for equals:
The text was updated successfully, but these errors were encountered: