Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/go/types/typeutil: stack overflow when hashing recursive embedded type interface #26863
What did you do?
What did you expect to see?
What did you see instead?
referenced this issue
Aug 8, 2018
I was going to ask if you (gri) could look into this, since it relates to what you've been thinking about a lot recently: cycles in types. What's the correct way to hash a cyclic type? Alternatively, what data structure should typeutil.Map use so that the issue doesn't arise? I can make the code change.
@alandonovan In Go, type cycles can only be constructed via type names (which may be aliases). I think that implies that those type names have to flow into the construction of the hash (even if they are aliases), and that we can't "simplify" interfaces containing named embedded interfaces by expanding the methods out. Or put differently, the text of a type's original (source code) declaration is a form of not very dense hash (except of course for names that need to be canonicalized, and formatting ignored, etc.).