cmd/compile: type..eq function not generated

[dotaheor]

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

go version go1.10.1 linux/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

package main

func main() {
	type T struct {
		a interface{}
		b int
	}
	
	var t T
	var z = [3]T{1: t}
	_ = z == z
}

What did you expect to see?

no errors

What did you see instead?

weird outputs, not like normal error messages.

type..eq.[3]main.T·1: call to external function
main.main: relocation target type..eq.[3]main.T·1 not defined
main.main: undefined: "type..eq.[3]main.T·1"

btw, gccgo is ok to compile this program.

[dotaheor]

More observations.

The following code compiles ok:

package main

func main() {
	type T struct {
		a interface{}
	}

	var z = [3]T{}
	_ = z
}

but the following one not

package main

func main() {
	type T struct {
		a interface{}
	}
	var z = [3]T{}
	_ = z == z
}

[dotaheor]

1.7 and 1.8 are ok. Not ok since 1.9.0.

[ALTree]

Since it's not clear from the report: to trigger the error, go run has to be used on the reproducer. The error is not printed when building, or when directly running a binary produced by go build.

Anyway, I've bisected this to 87065a3 (cmd/go: don't generate DWARF in the compiler if the linker will discard it).

cc @josharian

[josharian]

Sounds very similar to #22444. cc also @mdempsky

[dotaheor]

This problem also exists for go build.

package main

func f() {
	var a = []int{5: 0}

	a[0], a[1], a[2] = 0, 1, 2
}

So I think it should be fixed in 1.10.2.
And as soon as possible.

[dotaheor]

Sorry, I miss-typed main as f.
So the problem is gone if there is a main function.
Which makes it not so serious.

But this problem is really not go run specific.

[josharian]

@dotaheor the error message for package main with no func main is entirely unrelated to this issue. I thought there was already a (very old) issue suggesting a better error message when this happens, but I can't find it.

[josharian]

I believe that this is a duplicate of #23546.

[mvdan]

I was about to point out this being a duplicate too. The errors and programs are too similar for this to be a coincidence.

[ALTree]

Closing as a dup of #23546.