go/types: accepts weird invalid program

[josharian]

package p

var r = newReader()

func newReader() r

$ gotype x.go
$ go tool compile x.go 
x.go:3:9: typechecking loop involving newReader
	x.go:3:18 newReader()
	x.go:3:5 r = newReader()
	x.go:3:5 r
	x.go:5:15 <T>
	x.go:5:18 newReader
	x.go:5:6 <node DCLFUNC>
x.go:5:18: r is not a type

The cmd/compile error message is pretty ugly, but I'll file a separate issue for that.

Marking as unplanned, because of the oddity and unlikeliness of the program.

Found with go-fuzz.

[josharian]

@ianlancetaylor I'd be curious to know what gccgo does with this snowflake.

[ianlancetaylor]

gccgo output:

foo.go:5:18: error: expected type
 func newReader() r
                  ^
foo.go:3:9: error: reference to undefined name ‘newReader’
 var r = newReader()
         ^

[josharian]

gccgo definitely wins the compiler shootout on this one. :)

[griesemer]

go/types cycle detection has several issues. It's time to rethink/overhaul the mechanism.

[griesemer]

diff --git a/src/go/types/decl.go b/src/go/types/decl.go
index b1ae5ef3f2..b1e98d91fb 100644
--- a/src/go/types/decl.go
+++ b/src/go/types/decl.go
@@ -96,6 +96,7 @@ func (check *Checker) objDecl(obj Object, def *Named, path []*TypeName) {
                check.typeDecl(obj, d.typ, def, path, d.alias)
        case *Func:
                // functions may be recursive - no need to track dependencies
+               check.decl = d
                check.funcDecl(obj, d)
        default:
                unreachable()

leads to usable error message. Need to investigate further to see if that is the right approach.

(cycle detection in go/types could use a fundamental overhaul).

[griesemer]

Possibly related to Duplicate of #8699.

[gopherbot]

Change https://golang.org/cl/116815 mentions this issue: go/types: extend cycle detection past simple type cycles