[Bug go/100389] New: "invalid type conversion" error for string-based error type

[ben.hutchings at essensium dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100389

Bug ID: 100389
   Summary: "invalid type conversion" error for string-based error
type
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ben.hutchings at essensium dot com
CC: cmang at google dot com
  Target Milestone: ---

Given the following source files:

$ cat main.go
package main

import (
"foo"
"os"
)

func main() {
if !foo.IsInUse(foo.Remove()) {
os.Exit(1)
}
}
$ cat src/foo/foo.go
package foo

const (
errVolumeInUse conflictError = "volume is in use"
)

type conflictError string

func (e conflictError) Error() string {
return string(e)
}

func IsInUse(err error) bool {
return isErr(err, errVolumeInUse)
}

func isErr(err error, expected error) bool {
return err == expected
}

func Remove() error {
return errVolumeInUse
}

gccgo (from Debian package version 10.2.1-6) reports:

$ GOPATH=$PWD go build .
# _/home/bwh/tmp/gotest
 ./src/foo/foo.go:22: error: invalid type conversion (type has no methods)
 ./src/foo/foo.go:14: error: invalid type conversion (type has no methods)

Whereas gc (from Debian package version 1.15.9-1) builds these successfully.

[Bug go/100388] New: import seems to define identifiers in package block not file block

[ben.hutchings at essensium dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100388

Bug ID: 100388
   Summary: import seems to define identifiers in package block
not file block
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ben.hutchings at essensium dot com
CC: cmang at google dot com
  Target Milestone: ---

Given a package made of these two files:

$ cat a.go
package main

import (
copy "golang.org/x/sys/unix"
)

func Getuid() int {
return copy.Getuid()
}
$ cat b.go
package main

func main() {
foo := make([]string, 1)
bar := make([]string, 1)
copy(bar, foo)
}

gccgo seems to treat the imported "copy" as defined at package scope, shadowing
the global "copy":

$ go build .
# _/home/bwh/tmp/gotest
./b.go:6:2: error: ‘copy’ defined as both imported name and global name
6 |  copy(bar, foo)
  |  ^
./a.go:4:2: note: ‘copy’ imported here
4 |  copy "golang.org/x/sys/unix"
  |  ^

I'm seeing this with the Debian package of gccgo, version 10.2.1-6.

gc (again from a Debian package, version 1.15.9-1) does not report an error.

The Go Programming Language spec says that import declares names in the "file
block" which seems to mean it should not affect any other source file. But I am
a Go novice, so I might be misinterpreting this.