Skip to content
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

go/types: missing cycle errors #34333

Closed
griesemer opened this issue Sep 16, 2019 · 14 comments

Comments

@griesemer
Copy link
Contributor

commented Sep 16, 2019

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.

@griesemer griesemer added the NeedsFix label Sep 16, 2019
@griesemer griesemer added this to the Go1.14 milestone Sep 16, 2019
@griesemer griesemer self-assigned this Sep 16, 2019
@griesemer

This comment has been minimized.

Copy link
Contributor Author

commented Sep 16, 2019

[edited]
PS: This bug was introduced exposed with a80c5f0 .

@griesemer

This comment has been minimized.

Copy link
Contributor Author

commented Sep 16, 2019

This is a general cycle detection bug. Replacing interface with struct:

package p

type A struct {
	f func() B
	b B
}

type B struct {
	A
}

type-checks but it shouldn't.

@griesemer griesemer changed the title go/types: missing interface cycle error go/types: missing cycle errors for types that permit embedding Sep 16, 2019
@av86743

This comment has been minimized.

Copy link

commented Sep 17, 2019

Root cause:

Analysis of detailed design proposal (Jul-Sep 2019) is not based on formal model.

@griesemer

This comment has been minimized.

Copy link
Contributor Author

commented 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

This comment has been minimized.

Copy link

commented Sep 17, 2019

@griesemer

... the design proposal you're mentioning is not the root cause at all ...

This is not what I said. I said that "Analysis of ... proposal is [essentially absent]".

... in fact this bug has been around for an embarrassingly long time.

I certainly appreciate your recognition of the fact.

@griesemer

This comment has been minimized.

Copy link
Contributor Author

commented 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

This comment has been minimized.

Copy link

commented Sep 17, 2019

@griesemer

... 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.

@griesemer griesemer changed the title go/types: missing cycle errors for types that permit embedding go/types: missing cycle errors Sep 17, 2019
@griesemer

This comment has been minimized.

Copy link
Contributor Author

commented Sep 17, 2019

@av86743 Please see the updated title of this issue. It is unrelated to the proposal.

@av86743

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link
Contributor Author

commented 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

This comment has been minimized.

Copy link

commented Sep 17, 2019

@griesemer

[edited]
PS: This bug was introduced exposed with a80c5f0 .

Then what about this?

@griesemer

This comment has been minimized.

Copy link
Contributor Author

commented 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

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link

commented Sep 18, 2019

Change https://golang.org/cl/196338 mentions this issue: go/types: fix cycle detection

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.