cmd/compile: missing return value for undefined type mentions `<T>`

[dominikh]

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

$ go version
go version devel go1.21-e7201cfa9f Sat Feb 25 20:14:38 2023 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

package main

func foo() UnknownType {
	return
}

What did you expect to see?

A compile error that doesn't mention <T>

What did you see instead?

$ go build foo.go
# command-line-arguments
./foo.go:3:12: undefined: UnknownType
./foo.go:4:2: not enough return values
	have ()
	want (<T>)

[ianlancetaylor]

CC @griesemer

[cuonglm]

Seems to be a regression in new type checker, go1.17 only reports first error.

[gopherbot]

Change https://go.dev/cl/471438 mentions this issue: go/types, types2: avoid errors for invalid type in return statement

[griesemer]

Note that there are two separate, unrelated errors, and the compiler is correct to report both of them. I don't consider this a regression. (The 2nd error is not caused by the 1st one, i.e., it's not a follow-on error).

The report is on the printing of <T> which perhaps can be improved.

[griesemer]

@dominikh As mentioned above, I believe the compiler correctly reports two errors here, the issue is just the "spelling" of the <T>. For implementation reasons we don't have a good name for UnknownType when we produce the 2nd error, and - after looking into it a bit - it seems it would require quite a bit of plumbing to get the proper name to the place which reports the error. That's probably not justified just for this case, as it's not a common situation, I think.

Q: Do you have anything specific in mind about what else you'd like to see reported in this case? The <T> is a deliberate placeholder for a type about which we don't know more.

I am inclined to not do anything here. Thoughts?

[ianlancetaylor]

If we can't do better, I think that at least <unknownType> would be better than <T>.

[dominikh]

As mentioned above, I believe the compiler correctly reports two errors here, the issue is just the "spelling" of the <T>.

Agreed.

after looking into it a bit - it seems it would require quite a bit of plumbing to get the proper name to the place which reports the error.

That is unfortunate.

Q: Do you have anything specific in mind about what else you'd like to see reported in this case? The <T> is a deliberate placeholder for a type about which we don't know more.

I primarily filed this issue because I vaguely remember that including <T> in output was considered a compiler bug many years ago (although I cannot find a source for that…). I don't have concrete suggestions for a better placeholder, though I think Ian's suggestion is better than <T>, in particular now that T is a common name for type parameters, and people might not associate it with a placeholder.

Maybe to improve on Ian's suggestion we could even say <unknown type>, as that is impossible to be a valid identifier in any way.

[gopherbot]

Change https://go.dev/cl/473255 mentions this issue: go/types, types2: use "undefined type" rather than "<T>" in have/want error messages