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

cmd/go: program that shadows 'string' type fails to compile with go 1.11 #27584

Closed
zigo101 opened this issue Sep 9, 2018 · 19 comments
Closed
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@zigo101
Copy link

zigo101 commented Sep 9, 2018

Please answer these questions before submitting your issue. Thanks!

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

go version go1.11 linux/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

package main

type string = []int

func main() {
}

What did you expect to see?

run okay.

What did you see instead?

build error:

/tmp/go-build910164881/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tapp\nmod\tapp\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment

It runs okay with Go 1.10.3.

@agnivade
Copy link
Contributor

agnivade commented Sep 9, 2018

I am unable to reproduce this.

@zigo101
Copy link
Author

zigo101 commented Sep 9, 2018

It is only reproducible if the code is outside of GOPATH.

@agnivade
Copy link
Contributor

agnivade commented Sep 9, 2018

Still cannot reproduce.

@bmeh
Copy link

bmeh commented Sep 9, 2018

I cannot reproduce this error either using the same version, outside $GOPATH.

Could you please:

  1. provide the output of go env
  2. re-build it using go build -work file.go (-work will make sure the temporary work directory does not get deleted), and post the content of $WORK/b001/_gomod_.go? Depending on the amount of lines, you may want to use a pastebin.

I am not exactly sure how go build works, but perhaps it may be a good starting point.

@zigo101
Copy link
Author

zigo101 commented Sep 10, 2018

It looks it is not 100% reproducible.

I checked it on another computer, with the following tries, all are outside of GOPATH.

  1. A single main.go, go run main.go runs okay.
  2. Add a go.mod file, go run main.go prints the errors mentioned above.
  3. Remove the go.mod file, go run main.go runs okay again.
  4. Add back again the go.mod file, go run main.go continues to run okay.

On the first computer (not nearby now), go run main.go always prints the errors, whether the go.mod file exists or not. (When the first time the errors were printed, the go.mod file had existed there already.)

So I doubt that this problem might be related to cache.

@agnivade
Copy link
Contributor

For the cases, where you are able to reproduce, please provide the output by adding the -x flag.

@agnivade agnivade added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Sep 10, 2018
@zigo101
Copy link
Author

zigo101 commented Sep 10, 2018

Another one:

$ go run -work -x y.go 
WORK=/tmp/go-build148841673
mkdir -p $WORK/b001/
cat >$WORK/b001/_gomod_.go << 'EOF' # internal

		package main
		import _ "unsafe"
		//go:linkname __debug_modinfo__ runtime/debug.modinfo
		var __debug_modinfo__ string
		func init() {
			__debug_modinfo__ = "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\ta.b.c\nmod\ta.b.c\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
		}
	EOF
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile runtime=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime.a
EOF
cd /home/username/Desktop/y
/home/username/sdks/go-1.11/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p main -complete -buildid UHBYAsCe0dpuN23Mt_yP/UHBYAsCe0dpuN23Mt_yP -dwarf=false -goversion go1.11 -D _/home/username/Desktop/y -importcfg $WORK/b001/importcfg -pack -c=2 ./y.go $WORK/b001/_gomod_.go
# command-line-arguments
/tmp/go-build148841673/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\ta.b.c\nmod\ta.b.c\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment

@zigo101
Copy link
Author

zigo101 commented Sep 10, 2018

The new errors are some different:

$ go run -work -x z.go 
WORK=/tmp/go-build881444167
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile runtime=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime.a
EOF
cd /home/username/Desktop/z
/home/username/sdks/go-1.11/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p main -complete -buildid gNMKr6CFxeFcxHT43CI4/gNMKr6CFxeFcxHT43CI4 -dwarf=false -goversion go1.11 -D _/home/username/Desktop/z -importcfg $WORK/b001/importcfg -pack -c=2 ./z.go
/home/username/sdks/go-1.11/pkg/tool/linux_amd64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a /home/username/.cache/go-build/08/08b252bcff057a11a79a57407ed6aa24ecb48594498f60e2b08984df4c1be67a-d # internal
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile command-line-arguments=$WORK/b001/_pkg_.a
packagefile runtime=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime.a
packagefile internal/bytealg=/home/username/sdks/go-1.11/pkg/linux_amd64/internal/bytealg.a
packagefile internal/cpu=/home/username/sdks/go-1.11/pkg/linux_amd64/internal/cpu.a
packagefile runtime/internal/atomic=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime/internal/atomic.a
packagefile runtime/internal/sys=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime/internal/sys.a
EOF
mkdir -p $WORK/b001/exe/
cd .
/home/username/sdks/go-1.11/pkg/tool/linux_amd64/link -o $WORK/b001/exe/z -importcfg $WORK/b001/importcfg.link -s -w -buildmode=exe -buildid=kct7zM2i7B1u1xUGy9_J/gNMKr6CFxeFcxHT43CI4/q74ZA2q-PWwpJ49yWZKu/kct7zM2i7B1u1xUGy9_J -extld=gcc $WORK/b001/_pkg_.a
$WORK/b001/exe/z

@zigo101
Copy link
Author

zigo101 commented Sep 10, 2018

Aha, the last one looks succeeded.

@agnivade agnivade added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Sep 10, 2018
@agnivade agnivade added this to the Go1.12 milestone Sep 10, 2018
@agnivade
Copy link
Contributor

Something related to having a go.mod. @bcmills @myitcv

@zigo101
Copy link
Author

zigo101 commented Sep 10, 2018

Another success but with some different messages:

go run -work -x w.go
WORK=/tmp/go-build935203608
mkdir -p $WORK/b001/
cat >$WORK/b001/_gomod_.go << 'EOF' # internal

		package main
		import _ "unsafe"
		//go:linkname __debug_modinfo__ runtime/debug.modinfo
		var __debug_modinfo__ string
		func init() {
			__debug_modinfo__ = "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tw.w.w\nmod\tw.w.w\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
		}
	EOF
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile runtime=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime.a
EOF
cd /home/username/Desktop/w
/home/username/sdks/go-1.11/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p main -complete -buildid 7QpYSWkEkSs7VIu3HqeE/7QpYSWkEkSs7VIu3HqeE -dwarf=false -goversion go1.11 -D _/home/username/Desktop/w -importcfg $WORK/b001/importcfg -pack -c=2 ./w.go $WORK/b001/_gomod_.go
/home/username/sdks/go-1.11/pkg/tool/linux_amd64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a /home/username/.cache/go-build/bb/bb36be7532d0a4e187e9fa2839bde821522aec3ca06b0345bc2e9e2162d825c8-d # internal
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile command-line-arguments=$WORK/b001/_pkg_.a
packagefile runtime=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime.a
packagefile internal/bytealg=/home/username/sdks/go-1.11/pkg/linux_amd64/internal/bytealg.a
packagefile internal/cpu=/home/username/sdks/go-1.11/pkg/linux_amd64/internal/cpu.a
packagefile runtime/internal/atomic=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime/internal/atomic.a
packagefile runtime/internal/sys=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime/internal/sys.a
EOF
mkdir -p $WORK/b001/exe/
cd .
/home/username/sdks/go-1.11/pkg/tool/linux_amd64/link -o $WORK/b001/exe/w -importcfg $WORK/b001/importcfg.link -s -w -buildmode=exe -buildid=oBvIHRhWrsxBQcAZgS1v/7QpYSWkEkSs7VIu3HqeE/4KhN7m9lZuy5Nqxw8aEL/oBvIHRhWrsxBQcAZgS1v -extld=gcc $WORK/b001/_pkg_.a
$WORK/b001/exe/w

@myitcv
Copy link
Member

myitcv commented Sep 10, 2018

@go101 please can you confirm whether this is reproducible with a clean GOPATH

GOPATH=$(mktemp -d) ...

Or some such.

@zigo101
Copy link
Author

zigo101 commented Sep 10, 2018

It is still reproducible.

$ echo $GOPATH
/tmp/tmp.JYd4CgQRQO
$ go run -work -x main.go
WORK=/tmp/go-build111201820
mkdir -p $WORK/b001/
cat >$WORK/b001/_gomod_.go << 'EOF' # internal

		package main
		import _ "unsafe"
		//go:linkname __debug_modinfo__ runtime/debug.modinfo
		var __debug_modinfo__ string
		func init() {
			__debug_modinfo__ = "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tx.y.z\nmod\tx.y.z\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
		}
	EOF
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile runtime=/home/username/sdks/go/pkg/linux_amd64/runtime.a
EOF
cd /home/username/Desktop/ttt/main
/home/username/sdks/go/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p main -complete -buildid iOWIEHCnmfUtkkGBDey6/iOWIEHCnmfUtkkGBDey6 -dwarf=false -goversion go1.11 -D _/home/username/Desktop/ttt/main -importcfg $WORK/b001/importcfg -pack -c=4 ./main.go $WORK/b001/_gomod_.go
# command-line-arguments
/tmp/go-build111201820/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tx.y.z\nmod\tx.y.z\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment

@bcmills
Copy link
Contributor

bcmills commented Sep 11, 2018

@go101 I'm not able to reproduce this either. Are you sure you're on go1.11 and not a beta build?

Can you please attach the output of:

  • go version
  • go env
  • ls -alF in the working directory where you observed the failure
  • cat $(ls -a) in the working directory where you observed the failure
    ?
$ cd $(mktemp -d)

$ cat > main.go
package main

type string = []int

func main() {
}

$ GO111MODULE=on go run main.go
go: cannot find main module; see 'go help modules'

$ GO111MODULE=auto go run main.go

$ go mod init golang.org/issue/27584
go: creating new go.mod: module golang.org/issue/27584

$ GO111MODULE=auto go run main.go

$ GO111MODULE=on go run main.go

$ GO111MODULE=on go run -work -x main.go
WORK=/tmp/go-build714557646
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile command-line-arguments=/usr/local/google/home/bcmills/.cache/go-build/d1/d196d9ef20921c9218c105c00dd9d4e3b48c890c23cd6e22cfd1df0861a30ff1-d
packagefile runtime=/usr/local/google/home/bcmills/.cache/go-build/f7/f78b02701a2258207495ae331230229f7a783eb6bcb4598536f95864e105cd59-d
packagefile internal/bytealg=/usr/local/google/home/bcmills/.cache/go-build/b1/b12520ce7a489125f4c55ec17aef1bd06767656afa59e97d3b21a6a120c91914-d
packagefile internal/cpu=/usr/local/google/home/bcmills/.cache/go-build/b9/b9e2c28ed08e293048c34281598346bba4d75f10659a2f4a6e3fe791cecf7b18-d
packagefile runtime/internal/atomic=/usr/local/google/home/bcmills/go/pkg/linux_amd64/runtime/internal/atomic.a
packagefile runtime/internal/sys=/usr/local/google/home/bcmills/.cache/go-build/84/841d94aaeaa60033f04059a28cfc457c7b61a4fba0043d31971372e6f1774ff3-d
EOF
mkdir -p $WORK/b001/exe/
cd .
/usr/local/google/home/bcmills/go/pkg/tool/linux_amd64/link -o $WORK/b001/exe/main -importcfg $WORK/b001/importcfg.link -s -w -buildmode=exe -buildid=lRVIC48sUQmTkMk_LWDT/IOhpT8PNQeHMLk-3Pg66/28omyR3LaBPjH16HopHD/lRVIC48sUQmTkMk_LWDT -extld=gcc /usr/local/google/home/bcmills/.cache/go-build/d1/d196d9ef20921c9218c105c00dd9d4e3b48c890c23cd6e22cfd1df0861a30ff1-d
$WORK/b001/exe/main

$ GO111MODULE=auto go run -work -x main.go
WORK=/tmp/go-build484784602
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile command-line-arguments=/usr/local/google/home/bcmills/.cache/go-build/d1/d196d9ef20921c9218c105c00dd9d4e3b48c890c23cd6e22cfd1df0861a30ff1-d
packagefile runtime=/usr/local/google/home/bcmills/.cache/go-build/f7/f78b02701a2258207495ae331230229f7a783eb6bcb4598536f95864e105cd59-d
packagefile internal/bytealg=/usr/local/google/home/bcmills/.cache/go-build/b1/b12520ce7a489125f4c55ec17aef1bd06767656afa59e97d3b21a6a120c91914-d
packagefile internal/cpu=/usr/local/google/home/bcmills/.cache/go-build/b9/b9e2c28ed08e293048c34281598346bba4d75f10659a2f4a6e3fe791cecf7b18-d
packagefile runtime/internal/atomic=/usr/local/google/home/bcmills/go/pkg/linux_amd64/runtime/internal/atomic.a
packagefile runtime/internal/sys=/usr/local/google/home/bcmills/.cache/go-build/84/841d94aaeaa60033f04059a28cfc457c7b61a4fba0043d31971372e6f1774ff3-d
EOF
mkdir -p $WORK/b001/exe/
cd .
/usr/local/google/home/bcmills/go/pkg/tool/linux_amd64/link -o $WORK/b001/exe/main -importcfg $WORK/b001/importcfg.link -s -w -buildmode=exe -buildid=lRVIC48sUQmTkMk_LWDT/IOhpT8PNQeHMLk-3Pg66/28omyR3LaBPjH16HopHD/lRVIC48sUQmTkMk_LWDT -extld=gcc /usr/local/google/home/bcmills/.cache/go-build/d1/d196d9ef20921c9218c105c00dd9d4e3b48c890c23cd6e22cfd1df0861a30ff1-d
$WORK/b001/exe/main

$ GO111MODULE=off go run -work -x main.go
WORK=/tmp/go-build456535128
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile command-line-arguments=/usr/local/google/home/bcmills/.cache/go-build/d1/d196d9ef20921c9218c105c00dd9d4e3b48c890c23cd6e22cfd1df0861a30ff1-d
packagefile runtime=/usr/local/google/home/bcmills/.cache/go-build/f7/f78b02701a2258207495ae331230229f7a783eb6bcb4598536f95864e105cd59-d
packagefile internal/bytealg=/usr/local/google/home/bcmills/.cache/go-build/b1/b12520ce7a489125f4c55ec17aef1bd06767656afa59e97d3b21a6a120c91914-d
packagefile internal/cpu=/usr/local/google/home/bcmills/.cache/go-build/b9/b9e2c28ed08e293048c34281598346bba4d75f10659a2f4a6e3fe791cecf7b18-d
packagefile runtime/internal/atomic=/usr/local/google/home/bcmills/go/pkg/linux_amd64/runtime/internal/atomic.a
packagefile runtime/internal/sys=/usr/local/google/home/bcmills/.cache/go-build/84/841d94aaeaa60033f04059a28cfc457c7b61a4fba0043d31971372e6f1774ff3-d
EOF
mkdir -p $WORK/b001/exe/
cd .
/usr/local/google/home/bcmills/go/pkg/tool/linux_amd64/link -o $WORK/b001/exe/main -importcfg $WORK/b001/importcfg.link -s -w -buildmode=exe -buildid=lRVIC48sUQmTkMk_LWDT/IOhpT8PNQeHMLk-3Pg66/28omyR3LaBPjH16HopHD/lRVIC48sUQmTkMk_LWDT -extld=gcc /usr/local/google/home/bcmills/.cache/go-build/d1/d196d9ef20921c9218c105c00dd9d4e3b48c890c23cd6e22cfd1df0861a30ff1-d
$WORK/b001/exe/main

$ go version
go version go1.11 linux/amd64

@bcmills bcmills added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. modules labels Sep 11, 2018
@zigo101
Copy link
Author

zigo101 commented Sep 12, 2018

$ pwd
/home/username/Desktop/y
$
$ ls -alF
total 16
drwxr-xr-x  2 username username 4096 Sep 11 22:59 ./
drwxr-xr-x 17 username username 4096 Sep 11 22:58 ../
-rw-r--r--  1 username username   11 Sep 11 22:59 go.mod
-rw-r--r--  1 username username   52 Sep 11 22:47 main.go
$
$ cat go.mod 
module y.z
$
$ cat main.go 
package main

type string = []int

func main() {
}

$ go version
go version go1.11 linux/amd64
$
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/username/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/username/go"
GOPROXY=""
GORACE=""
GOROOT="/home/username/sdks/go-1.11"
GOTMPDIR=""
GOTOOLDIR="/home/username/sdks/go-1.11/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/username/Desktop/y/go.mod"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build091767303=/tmp/go-build -gno-record-gcc-switches"
$ 
$ GO111MODULE=on go run main.go
# command-line-arguments
/tmp/go-build163046371/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\ty.z\nmod\ty.z\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment
$ 
$ GO111MODULE=auto go run main.go
# command-line-arguments
/tmp/go-build331081691/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\ty.z\nmod\ty.z\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment
$ 
$ 
$ GO111MODULE=auto go run -work -x main.go
WORK=/tmp/go-build145205000
mkdir -p $WORK/b001/
cat >$WORK/b001/_gomod_.go << 'EOF' # internal

		package main
		import _ "unsafe"
		//go:linkname __debug_modinfo__ runtime/debug.modinfo
		var __debug_modinfo__ string
		func init() {
			__debug_modinfo__ = "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\ty.z\nmod\ty.z\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
		}
	EOF
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile runtime=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime.a
EOF
cd /home/username/Desktop/y
/home/username/sdks/go-1.11/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p main -complete -buildid Cp0-8lEldzB4fm49G6Y5/Cp0-8lEldzB4fm49G6Y5 -dwarf=false -goversion go1.11 -D _/home/username/Desktop/y -importcfg $WORK/b001/importcfg -pack -c=2 ./main.go $WORK/b001/_gomod_.go
# command-line-arguments
/tmp/go-build145205000/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\ty.z\nmod\ty.z\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment
$ 
$ cd /tmp/go-build145205000
username@bogon:/tmp/go-build145205000$ ls
b001
username@bogon:/tmp/go-build145205000$
username@bogon:/tmp/go-build145205000$ cd b001/
username@bogon:/tmp/go-build145205000/b001$ ls -alF
total 16
drwxr-xr-x 2 username username 4096 Sep 11 23:01 ./
drwx------ 3 username username 4096 Sep 11 23:01 ../
-rw-r--r-- 1 username username  291 Sep 11 23:01 _gomod_.go
-rw-r--r-- 1 username username   86 Sep 11 23:01 importcfg
username@bogon:/tmp/go-build145205000/b001$
username@bogon:/tmp/go-build145205000/b001$ cat _gomod_.go 

		package main
		import _ "unsafe"
		//go:linkname __debug_modinfo__ runtime/debug.modinfo
		var __debug_modinfo__ string
		func init() {
			__debug_modinfo__ = "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\ty.z\nmod\ty.z\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
		}
	username@bogon:/tmp/go-build145205000/b001$
username@bogon:/tmp/go-build145205000/b001$ cat importcfg 
# import config
packagefile runtime=/home/username/sdks/go-1.11/pkg/linux_amd64/runtime.a

@zigo101
Copy link
Author

zigo101 commented Sep 12, 2018

continue:

username@bogon:/tmp/go-build145205000/b001$ cd ~/Desktop/y
username@bogon:~/Desktop/y$ 
username@bogon:~/Desktop/y$ GO111MODULE=auto go run main.go
# command-line-arguments
/tmp/go-build025406373/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\ty.z\nmod\ty.z\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment
username@bogon:~/Desktop/y$ GO111MODULE=off go run main.go
username@bogon:~/Desktop/y$ GO111MODULE=auto go run main.go
username@bogon:~/Desktop/y$ GO111MODULE=on go run main.go
username@bogon:~/Desktop/y$ 

once GO111MODULE=off go run main.go is executed, the issue disappears for ever.

@zigo101
Copy link
Author

zigo101 commented Sep 12, 2018

Although this issue is not 100% reproducible. I do find it has a high possibility to reproduce by follow the following steps:


username@bogon:/tmp/go/a$ go version
go version go1.11 linux/amd64
username@bogon:/tmp/go$ pwd
/tmp/go
username@bogon:/tmp/go$ mkdir a
username@bogon:/tmp/go$ cd a
username@bogon:/tmp/go/a$ cat << EOF > main.go
> package main
> 
> type string = []int
> 
> func main() {
> }
> EOF
username@bogon:/tmp/go/a$ go run main.go 
username@bogon:/tmp/go/a$ cat << EOF > go.mod
> module a.foo
> EOF
username@bogon:/tmp/go/a$ go run main.go 
username@bogon:/tmp/go/a$ 
username@bogon:/tmp/go/a$ mkdir ../b
username@bogon:/tmp/go/a$ cd ../b
username@bogon:/tmp/go/b$ cat << EOF > main.go
> package main
> 
> type string = []int
> 
> func main() {
> }
> EOF
username@bogon:/tmp/go/b$ cat << EOF > go.mod
> module b.foo
> EOF
username@bogon:/tmp/go/b$ go run main.go 
# command-line-arguments
/tmp/go-build024759510/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tb.foo\nmod\tb.foo\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment

@bcmills bcmills changed the title cmd/go: program fails to compile with go 1.11 cmd/go: program that shadows 'string' type fails to compile with go 1.11 Sep 12, 2018
@bcmills bcmills removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Sep 12, 2018
@bcmills
Copy link
Contributor

bcmills commented Sep 12, 2018

Got a reproduction. Thanks for your persistence.

$ pushd $(mktemp -d)
/tmp/tmp.pwfzUa8wD1

$ cat > main.go
package main

type string = []int

func main() {
}

$ go mod init golang.org/issue/27584
go: creating new go.mod: module golang.org/issue/27584

$ go run main.go
# command-line-arguments
/tmp/go-build648240730/b001/_gomod_.go:7:24: cannot use "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tgolang.org/issue/27584\nmod\tgolang.org/issue/27584\t(devel)\t\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2" (type string) as type []int in assignment

@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Sep 12, 2018
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/134915 mentions this issue: cmd/go: avoid type names in __debug__modinfo__ variable injected in package main

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants