cmd/compile: incorrect error message when assigning an interface to a constant

[mundaym]

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

go version devel +68c7cb25a7 Wed Apr 4 12:18:29 2018 +0100 darwin/amd64

Does this issue reproduce with the latest release?

Yes (go version go1.10.1 darwin/amd64).

What did you do?

Compiled https://play.golang.org/p/jzbFN6k7Jhk

What did you expect to see?

./const.go:10:7: const initializer I((*T)(nil)) is not a constant

What did you see instead?

./const.go:10:12: cannot convert (*T)(nil) (type *T) to type I:
	*T does not implement I (missing F method)

*T does implement I so this error message is wrong. The real issue is that the RHS is not a valid constant.

Note that the correct error message is shown if the declaration of F() is moved to be above the assertion in the file (i.e. https://play.golang.org/p/9f2SQfBfteA). If the const is changed to var then the program compiles correctly regardless of where F is declared.

[mvdan]

go/types gets this right, which further confirms your thinking:

f.go:10:11: I((*T)(nil)) (value of type I) is not constant

[odeke-em]

Thank you for reporting this @mundaym

/cc @mdempsky @griesemer

[mvdan]

Smaller repro:

package p

type I interface{ F() }
type T struct{}

const _ = I(T{})

func (T) F() {}

[mvdan]

The issue seems to stem from how gc is designed. Reading main.go, I see how it typechecks nodes in phases:

// Phase 1: const, type, and names and types of funcs.
[...]
// Phase 2: Variable assignments.

So it seems to me like a possible fix would be to insert an extra phase before "variable assignments" called "constant declarations". That way, in our example above, func (T) F() would always be typechecked before const _ = I(T{}).

@griesemer @mdempsky thoughts? Is there a better way to fix this issue? (Edit: ended up sending this as a CL - see below)

[mvdan]

I guess that another potential fix would be to detect if we're in phase 1 in the typechecker, and avoid giving errors like missing F method. After all, there is no guarantee that all methods have been typechecked and added to their respective types until we're past that phase. But it seems like special-casing all these errors would be a game of whack-a-mole.

[gopherbot]

Change https://golang.org/cl/115096 mentions this issue: cmd/compile: typecheck types and funcs before consts

[griesemer]

Let's leave this alone for 1.11. It's more subtle that it seems (see my comments on the issue) and it's definitively not urgent.

[mdempsky]

Sorry I missed this issue and CL until now.

I'm not convinced the committed fix fully addresses this. Typechecking package-scope declarations can't really be split into phases; there's always a way to construct code that depends on any particular kind of declaration being typechecked before any other.

E.g., this test case still repros the issue:

package p

import "unsafe"

type x [unsafe.Sizeof(w)]int

type I interface{ F() }
type T struct{}

const w = I(T{})

func (T) F() {}

(And as a more superficial issue, there are now two phase "3"s in main.go.)

[griesemer]

@mdempsky Agreed, I have also mentioned this in the CL (but the quick test case I tried to create didn't produce an error - see my CL feedback).