cmd/compile: expression calling an undefined method gets adorned with receiver's type in error message

[jfrech]

Compiling the following on the Go playground (go version 1.25; cf. https://go.dev/play/p/fTm-OR3aJ3a [2025-10-29])

package main

type S struct{}

func (S) G() {}

func main() {
	var s S
	_ = must(s.F())
}

func must[T any](x T, err error) T {
	if err != nil {
		panic(err)
	}
	return x
}

gives the rather thought-provoking two error messages:

./prog.go:10:11: not enough arguments in call to must
	have (S)
	want (T, error)
./prog.go:10:13: s.F undefined (type S has no field or method F)

Regarding the first one, I would have expected something along the lines of:

	have (undefined)

[adonovan]

It looks like the type checker is computing the type S for expression s.F(), but that's not what is actually reported in the go/types API; the call has no type at all:

I suspect that means the logic comes from the special handling of f(g()) CallExprs for the case where g has multiple results. In other words, the behavior doesn't decompose simply into x = g(); f(x). Indeed, it does not: https://go.dev/play/p/Cgf_1Hibr3D

I agree that the type checker could do better.

[gabyhelp]

Related Issues

• cmd/compile: Better error message when failing to provide a receiver for a method expression #8385 (closed)
• go/types: not enough arguments error message should be easier to skim #26249 (closed)
• cmd/compile: improve compiler error message when accessing type instead of instance of type #6814
• cmd/compile: confusing "cannot call non-function" error when a field is ambiguous #28268 (closed)
• go/types: better error message for invalid method receiver #27996 (closed)
• cmd/compile: generic error does not identify relevant type #64276 (closed)
• cmd/compile: failing type inference produces unclear error message #60542 (closed)
• cmd/compile: bad error message for argument missing type #69506 (closed)
• cmd/compile: improve error message when a method expression references ambiguous method name #14321 (closed)
• cmd/compile: unhelpful error message with recursive constraint #61685

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mknyszek]

CC @griesemer @mrkfrmn

[gopherbot]

Change https://go.dev/cl/716300 mentions this issue: go/types, types: proceed with correct (invalid) type in case of a selector error