cmd/compile: unexpected behavior difference between global and in-function variable definition

[dcarbone]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.7.5 darwin/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/dcarbone/code/golang"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.7.5/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.7.5/libexec/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/2c/s7sg4r5s1td507l7sglm2pzw9l4z5w/T/go-build267410383=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

Works:

package main

import "fmt"

type mytype struct {
	_ string
}

var foo = mytype{"foo"}

func main() {
	fmt.Printf("%#v\n", foo)
}

Fails:

package main

import "fmt"

type mytype struct {
	_ string
}

func main() {
	var foo = mytype{"foo"}
	fmt.Printf("%#v\n", foo)
}

What did you expect to see?

Either both fail or both succeed

What did you see instead?

When defining the variable in global space, the script executes. When attempting to define the variable within the main function, the script fails to compile.

Apologies if this is expected behavior, but I was unable to locate any documentation indicating as much.

[josharian]

Reproduced with tip. The error message is:

x.go:10: cannot refer to blank field or method

This seems odd to me too.

[josharian]

I don't see anything in https://golang.org/ref/spec#Composite_literals that forbids this.

[josharian]

cc @mdempsky

[spellgen]

Is there any intended use of a blank identifier for the field name other than padding in structs?

[ENACaseyBoone]

Just to add, we found structs with underscore entries in some source code and had no idea what it was intended to do. Someone in the Gophers Slack group said that the underscore entry would make it so you were forced to use named field constructors and not lazy construction. While playing with this, @dcarbone found that the behavior changed depending on if you tried to create the var in global or in local scope

[ianlancetaylor]

Both versions compile with gccgo.

[odeke-em]

Not necessarily related to, but it reminds me of #15481 (comment) in which
the bug report was spurious "cannot use _ as value" error and I noticed that https://play.golang.org/p/hz5ePuCDlF

package main

type m map[string]string

var _ = map[string]string{}       // ok
var _ = map[string]string{"": ""} // ok

func main() {
	var _ = map[string]string{}           // ok
	var _ = map[string]bool{}             // ok
	var _ = map[string]string{"a": "A"}   // error: cannot use _ as value
	var _ = map[string]bool{"true": true} // error: cannot use _ as value
}

had different results in the global vs function, somewhat similar to the _ check when in a function but successful compilation in the global scope.

[cespare]

cc @griesemer

[griesemer]

This is just a bug in the compiler.

It's clearly correct code (and gccgo and gotype accept this). May or may not be related to #15481 (see @odeke-em 's comment above).

[josharian]

Unrelated to #15481, as far as I can tell.

[gopherbot]

CL https://golang.org/cl/38006 mentions this issue.