-
Notifications
You must be signed in to change notification settings - Fork 18k
go/types: missing cycle errors #34333
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
[edited] |
This is a general cycle detection bug. Replacing package p
type A struct {
f func() B
b B
}
type B struct {
A
} type-checks but it shouldn't. |
Root cause: Analysis of detailed design proposal (Jul-Sep 2019) is not based on formal model. |
@av86743 Thanks, but the design proposal you're mentioning is not the root cause at all - it is in fact unrelated. It just so happens that I changed the implementation of interface type-checking entirely when implementing overlapping interfaces, which in turn exposed an underlying bug. As I have mentioned here, this bug also appears for structs which have nothing to do with interfaces; in fact this bug has been around for an embarrassingly long time. |
This is not what I said. I said that "Analysis of ... proposal is [essentially absent]".
I certainly appreciate your recognition of the fact. |
@av86743 Hm, apologies for the misunderstanding, but I don't understand what you are saying. Since the specific proposal is unrelated to this bug, I don't see why you bring in that proposal in the first place. |
This proposal is the first and only place where you specify (in section "Proposal") what you are intending to do. It also indicates a period when implementation has taken place. |
Your example with structs does not type-check with current go1.12 (and likely with earlier go versions) - as it should. It started to fail only after "unrelated" changes per said proposal. Think a moment about it. |
Then what about this? |
"... bug was exposed with [commit]" is rather strange choice of wording if you admit that regression in cycle detection appeared before commit was applied (or even existed.) Clearly, the initial interface example is not part of the commit in question but was somehow arrived at, at a later time. Which in turn translates into "... bug was not exposed with [commit]". Hence the root cause. |
Change https://golang.org/cl/196338 mentions this issue: |
produces:
"illegal cycle in declaration of A"
with go/types. But when we introduce a methodm
such as in:the error disappears and the code typechecks. If
m
is declared after the embedded interfaceB
, the error appears again.This is an ordering issue in
go/types
.The text was updated successfully, but these errors were encountered: