-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: using non-exported generic type causes internal compiler error #48337
Comments
Seems inlining problem, it's build ok with:
and unified IR. cc @danscales |
I have an alternate reproducer that seems to demonstrate the same issue without using any standard library imports, and gives an error that might point more closely at the underlying problem. $ gotip version go version devel go1.18-ad97d204f0 Sun Sep 12 16:46:58 2021 +0000 linux/amd64
|
The two cases listed look like distinct issues. The second case is due to the fact that we are not correctly exporting/importing the IsShape/HasShape flag when importing shape types. We are importing shape types as part of importing functions like NewMetaContainer (including calls to stenciled functions with shape type params) as needed for inlining. If we isolate the knowledge to the types package, we can probably set the IsShape flag based on the type being in the shapes package. That may be preferable to changing the export format to know about an IsShape flag or a shape type. @randall77 I haven't tried to analyze the first issue yet. |
Change https://golang.org/cl/349869 mentions this issue: |
Change https://golang.org/cl/349909 mentions this issue: |
Move ShapePkg to types, and change types.NewNamed to automatically set IsShape/HasShape if a type is in the shapes pkg. This means that imported shape types will automatically have the correct IsShape/HasShape flags, even though we are not explicitly exporting/importing those flags. Updates #48337 Change-Id: I8b6131a663205f73f395943c9d0c8bdb2a213401 Reviewed-on: https://go-review.googlesource.com/c/go/+/349869 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
There are a bunch of nodes beside ONAME and OTYPE, (such as OSTRUCTLIT and OCOMPLIT) which can introduce a generic type that we need to mark. So, just mark any generic type on any node in markInlBody. In this particular issue, the type is introduced by an OSTRUCTLIT node. Updates #48337 Change-Id: I271932518f0c1fb54d91a603e01a855c69df631d Reviewed-on: https://go-review.googlesource.com/c/go/+/349909 Trust: Dan Scales <danscales@google.com> Trust: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
I believe both issues described in the issue are fixed now. |
I was getting the same error with other code (using latest master) so I made another reproducer. go test ./... from project root. Full error# mir/common/pbadapt [mir/common/pbadapt.test] /Users/ilya/Development/gobugs/missingimportreader/vendor/github.com/IlyaFloppy/observable/object.go:14:13: internal compiler error: missing import reader for sync.(*Mutex).Lock Should I open another issue for this one? |
We can use this issue for the new case as well. I have a fix, but want to do more checking to make sure to get a general solution for these issues (which relate to exporting the types/functions bodies needed for inlining, as related to generic types that have unexported fields). Issue #48454 has similar problem/cause. |
Change https://golang.org/cl/351315 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
-
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
https://github.com/IlyaFloppy/strangeimports
What did you expect to see?
Successful compilation
What did you see instead?
internal compiler error: missing import reader for sync.(*Mutex).Lock
Full error
Adding imports in a file which uses provided code makes the error go away
Returning value of exported type in
NewWrapperWithLock[T any](value T) WrapperWithLock[T]
also makes code compile without errorsThe text was updated successfully, but these errors were encountered: