cmd/compile: unexpected behavior difference between global and in-function variable definition #19482
Comments
josharian
changed the title
|
Reproduced with tip. The error message is:
This seems odd to me too. |
|
I don't see anything in https://golang.org/ref/spec#Composite_literals that forbids this. |
|
cc @mdempsky |
|
Is there any intended use of a blank identifier for the field name other than padding in structs? |
|
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 |
|
Both versions compile with gccgo. |
|
Not necessarily related to, but it reminds me of #15481 (comment) in which 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. |
|
cc @griesemer |
|
Unrelated to #15481, as far as I can tell. |
|
CL https://golang.org/cl/38006 mentions this issue. |
Given code such as
type T struct {
_ string
}
func f() {
var x = T{"space"}
// ...
}
the compiler rewrote the 'var x' line as
var x T
x._ = "space"
The compiler then rejected the assignment to
a blank field, thus rejecting valid code.
The only way such an assignment is legal
is to use a composite literal in which
the struct fields are provided implicitly.
When we encounter such struct fields,
mark them as allowing assignment to a blank field,
and check for the exception at the right moment.
Fixes golang#19482
Change-Id: I594476171d15e6e8ecc6a1749e3859157fe2c929
Given code such as
type T struct {
_ string
}
func f() {
var x = T{"space"}
// ...
}
the compiler rewrote the 'var x' line as
var x T
x._ = "space"
The compiler then rejected the assignment to
a blank field, thus rejecting valid code.
It also failed to catch a number of invalid assignments.
And there were insufficient checks for validity
when emitting static data, leading to ICEs.
To fix, check earlier for explicit blanks field names,
explicitly handle legit blanks in sinit,
and don't try to emit static data for nodes
for which typechecking has failed.
Fixes golang#19482
Change-Id: I594476171d15e6e8ecc6a1749e3859157fe2c929
Reviewed-on: https://go-review.googlesource.com/38006
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go version go1.7.5 darwin/amd64What operating system and processor architecture are you using (
go env)?What did you do?
Works:
Fails:
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
mainfunction, the script fails to compile.Apologies if this is expected behavior, but I was unable to locate any documentation indicating as much.
The text was updated successfully, but these errors were encountered: