Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dominikh opened this issue Feb 26, 2023 · 8 comments
Closed

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

dominikh opened this issue Feb 26, 2023 · 8 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@dominikh
Copy link
Member

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>)
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 26, 2023
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 26, 2023
@ianlancetaylor ianlancetaylor added this to the Backlog milestone Feb 26, 2023
@ianlancetaylor
Copy link
Contributor

CC @griesemer

@cuonglm
Copy link
Member

cuonglm commented Feb 27, 2023

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

@gopherbot
Copy link
Contributor

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

@griesemer
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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

@dominikh
Copy link
Member Author

dominikh commented Mar 3, 2023

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
Copy link
Contributor

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

@golang golang locked and limited conversation to collaborators Mar 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

6 participants