Closed
Description
package p
type A interface {
B
}
type B interface {
A
}produces: "illegal cycle in declaration of A" with go/types. But when we introduce a method m such as in:
package p
type A interface {
m() B
B
}
type B interface {
A
}the error disappears and the code typechecks. If m is declared after the embedded interface B, the error appears again.
This is an ordering issue in go/types.
Metadata
Metadata
Assignees
Labels
Type
Projects
Relationships
Development
No branches or pull requests
Participants
Activity
griesemer commentedon Sep 16, 2019
[edited]
PS: This bug was
introducedexposed with a80c5f0 .griesemer commentedon Sep 16, 2019
This is a general cycle detection bug. Replacing
interfacewithstruct:type-checks but it shouldn't.
[-]go/types: missing interface cycle error[/-][+]go/types: missing cycle errors for types that permit embedding[/+]av86743 commentedon Sep 17, 2019
Root cause:
Analysis of detailed design proposal (Jul-Sep 2019) is not based on formal model.
griesemer commentedon Sep 17, 2019
@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.
av86743 commentedon Sep 17, 2019
@griesemer
This is not what I said. I said that "Analysis of ... proposal is [essentially absent]".
I certainly appreciate your recognition of the fact.
griesemer commentedon Sep 17, 2019
@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.
av86743 commentedon Sep 17, 2019
@griesemer
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.
[-]go/types: missing cycle errors for types that permit embedding[/-][+]go/types: missing cycle errors[/+]griesemer commentedon Sep 17, 2019
@av86743 Please see the updated title of this issue. It is unrelated to the proposal.
av86743 commentedon Sep 17, 2019
@griesemer
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.
griesemer commentedon Sep 17, 2019
@av86743 The latest released version is go1.13 (commit cc8838d), and on my machine the struct example is (incorrectly) accepted. This code failed before said proposal was proposed or implemented.
av86743 commentedon Sep 17, 2019
@griesemer
Then what about this?
griesemer commentedon Sep 17, 2019
@av86743 Initial guess/misdiagnosis - which is why I corrected it once I realized that this was unrelated. The problem is due to how cycle detection was changed a while back. Anyway, I consider this discussed resolved at this point. Thanks.
av86743 commentedon Sep 17, 2019
"... 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.
gopherbot commentedon Sep 18, 2019
Change https://golang.org/cl/196338 mentions this issue:
go/types: fix cycle detection