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
types2, go/types: embedding comparable ignores other type set constraints #47411
Labels
Milestone
Comments
griesemer
added
the
NeedsFix
The path to resolution is known, but the work has not been done.
label
Jul 26, 2021
cc: @findleyr |
Change https://golang.org/cl/337354 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jul 27, 2021
…er than ==() method This removes the special "==" methods from comparable interfaces in favor of a "comparable" flag in TypeSets indicating that the interface is or embeds comparable. Fixes various related implementation inaccuracies. While at it, fix setup of the predeclared error and comparable interface types by associating their respective type name objects with them. For #47411. Change-Id: I409f880c8c8f2fe345621401267e4aaabd17124d Reviewed-on: https://go-review.googlesource.com/c/go/+/337354 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Change https://golang.org/cl/339652 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Aug 4, 2021
This is a port of CL 337354 to go/types, adjusted for the error reporting API and to reposition a couple error messages in issue47411.go2 (the go/types position is probably better). A panic is also fixed in lookup.go when method lookup fails and static == false. I'll send a fix for types2 in a separate CL. For #47411 Change-Id: Icc48f03c3958695f581f10e8675c1f32434c424b Reviewed-on: https://go-review.googlesource.com/c/go/+/339652 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
This was fixed with the CLs above in the |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
should fail to type check because the type set of
P
is the intersection of all types that are comparable and all map types with underlying typemap[string]int
, and since map types are not comparable, the intersection is empty. Thus, there is no type that satisfies thecomparable
constraint forg
.Example adjusted for go2go playground: this fails as expected, but this succeeds unexpectedly.
The text was updated successfully, but these errors were encountered: