-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
cmd/compile/internal/importer, go/internal/importer (+friends): can't import 'any' underlying #49888
Comments
Change https://golang.org/cl/367851 mentions this issue: |
Looked at this a bit more. The original problem is that we use the LHS of type declaration as the receiver type in interface methods on the RHS, so such RHS interfaces can't be reused. Possibly we could stop doing this, but that's not a decision for now. To fix this bug, we can just allow reusing empty interfaces. |
This issue is currently filed as release blocking and not okay after beta 1, so the Go 1.18 beta 1 is being blocked on it. |
Yes, this is definitely a release blocker. The CL to fix it is pending. |
Change https://golang.org/cl/368254 mentions this issue: |
Change https://golang.org/cl/368354 mentions this issue: |
type decls This is a port of CL 367851 to x/tools. The test set-up is slightly different; I added a TODO to converge. Updates golang/go#49888 Change-Id: I31a63c1fc8f9a78526d8eea05fd01dae35770b5f Reviewed-on: https://go-review.googlesource.com/c/tools/+/368354 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
The following logic is replicated to a few of our importers:
https://cs.opensource.google/go/go/+/master:src/go/internal/gcimporter/iimport.go;l=258;drc=f90a42b41080cf5a289f151f2166d0d0a795e836
As a result, we don't use the cached, predeclared
any
when considering the RHS of a type declaration, as inWhen importing this code, we get
(it is unfortunate that we did not add test coverage for this pattern, once
any
was allowed out of constraint position)Notably,
cmd/compile/internal/typecheck
does not appear to have this problem:https://cs.opensource.google/go/go/+/master:src/cmd/compile/internal/typecheck/iimport.go;l=745;drc=229b90931312aa1686f4bace25d1f40f896884ad
Discussing with @griesemer, we're not sure why that guard is necessary. Certainly it seems OK to add an exception for
any
there. If this doesn't work out, we may need to revert #49583, which would be unfortunate.CC @mdempsky and @danscales who may have additional context, @heschi for awareness.
The text was updated successfully, but these errors were encountered: