-
Notifications
You must be signed in to change notification settings - Fork 18.1k
x/tools/go/types/typeutil: infinite recursion with cyclic interface type #56048
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
This crash isn't in NumMethods. It's an infinite recursion in |
You're right, NumMethods just happens to be the frame the broke the camel's stack, as it were. |
The root cause is that it is not sufficient to break cycles at Named types, because Interface.Methods "looks through" the named type of an embedded interface, thus typeutil's hasher will never encounter the named type X during its traversal of a type such as I notice a nice comment to this effect in types.Identical:
So we may need to prune the recursion at method names too. We should also document the subtleties of the correct approach to bounded recursion over types in go/types. typeutil test case:
|
Is this related to #26863? |
Change https://go.dev/cl/439117 mentions this issue: |
Thanks @dominikh, seems like a dup. |
In a type such as type X interface { m() []*interface { X } } the traversal never encounters the named type X in the result of m since Interface.Methods expands it to a set of methods, one that includes m, causing the traversal to get stuck. This change uses an alternative, shallow hash function on the types of interface methods to avoid the possibility of getting stuck in such a cycle. (An earlier draft used a stack of interface types to detect cycles, but the logic of caching made this approach quite tricky.) Fixes golang/go#56048 Fixes golang/go#26863 Change-Id: I28a604e6affae5dfdd05a62e405d49a3efc8d709 Reviewed-on: https://go-review.googlesource.com/c/tools/+/439117 gopls-CI: kokoro <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Tim King <[email protected]> Run-TryBot: Alan Donovan <[email protected]>
@gri @findleyr @mdempsky @timothy-king
The text was updated successfully, but these errors were encountered: