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

Jump to bottom

cmd/go2go: cannot refer to unexported name "pkg.unexported" #43888

Closed
benburkert opened this issue Jan 25, 2021 · 5 comments
Closed

cmd/go2go: cannot refer to unexported name "pkg.unexported" #43888

benburkert opened this issue Jan 25, 2021 · 5 comments
Labels
FrozenDueToAge

Comments

@benburkert
Copy link
Contributor

benburkert commented Jan 25, 2021 •
edited

What version of Go are you using (go version)?

$ go version
go version devel +79f7966688 Tue Jan 12 16:41:23 2021 +0000 darwin/amd64

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/benburkert/Library/Caches/go-build"
GOENV="/Users/benburkert/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/benburkert/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/benburkert"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/benburkert/src/github.com/golang/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/benburkert/src/github.com/golang/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/3q/b_j95bxn6_n4z99hyl_8r41r0000gn/T/go-build350165288=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version devel +79f7966688 Tue Jan 12 16:41:23 2021 +0000 darwin/amd64
GOROOT/bin/go tool compile -V: compile version devel +79f7966688 Tue Jan 12 16:41:23 2021 +0000
uname -v: Darwin Kernel Version 20.2.0: Wed Dec  2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64
ProductName:	macOS
ProductVersion:	11.1
BuildVersion:	20C69
lldb --version: lldb-1103.0.22.10
Apple Swift version 5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53)

What did you do?

$ cat main.go2

package main

import "subpkg"

func main() {
  subpkg.Hello[string]()
}

$ cat subpkg/pkg.go2

package subpkg

import "fmt"

func Hello[T any]() {
  var t T
  hello(t)
}

func hello(t interface{}) {
  fmt.Printf("hello, here's a zero %T: %#v\n", t, t)
}

What did you expect to see?

$ go tool go2go run ./main.go2
hello, here's a zero string: ""

What did you see instead?

$ go tool go2go run ./main.go2
# command-line-arguments
/tmp/main.go2:6: cannot refer to unexported name subpkg.hello
/tmp/main.go2:6: undefined: subpkg.hello
/path/to/go/bin/go [run main.go] failed: exit status 2

Exporting the hello func fixes the compile error.
@mdempsky mdempsky changed the title go2go: cannot refer to unexported name "pkg.unexported" cmd/go2go: cannot refer to unexported name "pkg.unexported" Jan 25, 2021
@toothrot
Copy link
Contributor

/cc @findleyr @griesemer @ianlancetaylor

@griesemer
Copy link
Contributor

This is an unfortunate limitation of the go2go prototype: Since it relies on monomorphization - i.e., "expansion" of all generic code into non-generic code, the non-generic code for Hello[string] wants to call subpkg.hello which is not exported.

It's not clear to me that we want/need to fix this in the prototype.

@ianlancetaylor
Copy link
Contributor

This is a documented limitation of the go2go tool.

https://go.googlesource.com/go/+/refs/heads/dev.go2go/src/cmd/go2go/doc.go#49

@benburkert
Copy link
Contributor Author

@griesemer @ianlancetaylor thanks for the explanation. Out of curiosity, could a go:linkname directive work here?

@ianlancetaylor
Copy link
Contributor

For the special case of calling a package-scope unexported function, yes, go:linkname could work. It wouldn't help for a reference to an unexported method or an unexported type.

@golang golang locked and limited conversation to collaborators Jan 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@benburkert @toothrot @ianlancetaylor @griesemer @gopherbot