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, types2: incorrect behavior of API methods on invalid unions #49739

Open
findleyr opened this issue Nov 23, 2021 · 4 comments
Open

go/types, types2: incorrect behavior of API methods on invalid unions #49739

findleyr opened this issue Nov 23, 2021 · 4 comments
Assignees
Labels
Milestone

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Nov 23, 2021

Consider the following code:

package p

type A int
type B int
type C interface{string}

type X interface{~A}
type Y interface{~B}
type Z interface{~int; C}

In this example, we have the following surprising behavior:

  • Identical(X.Type().Underlying(), Y.Type().Underlying()) == true
  • Implements(X.Type().Underlying(), Y.Type().Underlying()) == true
  • X.Type().Underlying().(*Interface).typeSet().IsEmpty() == false
  • Identical(X.Type().Underlying(), Z.Type().Underlying)) == false

The type set of X should be empty, per the update to the spec in https://golang.org/cl/362999. Are two interfaces with empty type sets identical? It's not clear to me, but we should be consistent.

CC @griesemer

*found via fuzzing.

@griesemer griesemer self-assigned this Nov 23, 2021
@griesemer griesemer added this to the Go1.18 milestone Nov 23, 2021
@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 23, 2021

Interfaces that define the same type set are identical. This may be too abstract for the spec, so perhaps we can rephrase a bit.

Loading

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Nov 23, 2021

Ok. But this is not just a documentation issue. There is a bug in our handling of interface{~A}, where A is defined: we raise an error but return an interface that is non-empty but has no concrete types that implement it (only interface types).

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 23, 2021

Change https://golang.org/cl/366278 mentions this issue: cmd/compile/internal/types2: produce empty type set for invalid ~T

Loading

gopherbot pushed a commit that referenced this issue Nov 24, 2021
If ~T is not permitted because the underlying type of T is not the
same as T, there is no type that satisfies ~T. Besides reporting an
error, also ensure that the corresponding type set is empty.

For #49739.

Change-Id: I127f75f170902e7989f7fe7b352dabda9f72e2a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/366278
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 26, 2021

Change https://golang.org/cl/367197 mentions this issue: go/types: produce empty type set for invalid ~T

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants