gccgo: compiler does not detect illegal assignment to a private struct member

[davecheney]

What steps will reproduce the problem?

lucky(~/src) % cat a/a.go 
package a

type MyError struct {
        error
}
lucky(~/src) % cat b/b.go
package b

import "errors"
import "a"

func F() error {
        return &a.MyError{errors.New("plop")}
}

What is the expected output? What do you see instead?

Expected:

lucky(~/src) % go build -compiler gc b
# b
b/b.go:7: implicit assignment of unexported field 'error' in a.MyError literal

Got:

lucky(~/src) % go build -compiler gccgo b
lucky(~/src) % echo $?
0

Please use labels and text to provide additional information.

[rsc]

Comment 1:

Labels changed: added go1.3maybe.

[gopherbot]

Comment 2 by r@rcrowley.org:

This feature of gc was actually introduced in 1.2, as well.  We use a struct defined
pretty much like Dave's a.MyError above which works just fine in Go 1.1.2 but began
failing as Dave shows above with Go 1.2.
Was there a change that made such assignments illegal?  By the lexical rules for
exported/unexported the 1.2 behavior seems right but I've always seen error (and string,
map, append, copy, len, cap, new, make, etc.) as special and above that rule.

[davecheney]

Comment 3:

> Was there a change that made such assignments illegal?  By the lexical rules for
exported/unexported the 1.2 behavior seems right but I've always seen error (and string,
map, append, copy, len, cap, new, make, etc.) as special and above that rule.
Nope, these assignments have always been illegal, but this is enforced at compile time,
not runtime so if the compiler didn't stop them, nothing will.

[wadey]

Comment 4:

I think this change to "fix" the enforcement in go1.2 should have been documented in the
release notes, as it did break existing programs that worked in go1.1.2. Was this just
overlooked?

[ianlancetaylor]

Comment 5:

>I think this change to "fix" the enforcement in go1.2 should have been documented in
the release notes, as it did break existing programs that worked in go1.1.2. Was this
just overlooked?
Yes, probably.  You may want to open a separate doc issue for that.

[ianlancetaylor]

Comment 6:

Gccgo will not be part of the Go 1.3 release.

Labels changed: removed go1.3maybe.

[rsc]

Comment 7:

Labels changed: added repo-gccgo.

[paranoiacblack]

Fixed in gcc.gnu.org/r219313.