-
Notifications
You must be signed in to change notification settings - Fork 18k
go/types, types2: incorrect behavior of API methods on invalid unions #49739
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
Interfaces that define the same type set are identical. This may be too abstract for the spec, so perhaps we can rephrase a bit. |
Ok. But this is not just a documentation issue. There is a bug in our handling of |
Change https://golang.org/cl/366278 mentions this issue: |
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>
Change https://golang.org/cl/367197 mentions this issue: |
This is a clean port of CL 366278 from types2 to go/types. For #49739. Change-Id: I2e2cb739c02fcc07e012499c7b65b13b057875ea Reviewed-on: https://go-review.googlesource.com/c/go/+/367197 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
@findleyr Is there anything left to do here? |
ping |
Thanks, I think this is done. Closing. |
Consider the following code:
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.
The text was updated successfully, but these errors were encountered: