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: more helpful "is not a type" error when variable shadows type #23065

Open
cramertj opened this Issue Dec 9, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@cramertj

cramertj commented Dec 9, 2017

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

Current playground version.

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

Unknown (plaground).

What did you do?

The following code compiles with fancyMap is not a type errors in both foo and foo2 (playground):

package main

type fancyMap = map[string]string

func foo(fancyMap fancyMap) {
	var _ fancyMap
}

func foo2(fancyMap fancyMap) {
	_ = make(fancyMap)
}

func main() {
}

What did you expect to see?

Successful compilation or a more informative error message.

What did you see instead?

Poor/incorrect error message. Simply renaming the fancyMap variable fixes the problem, but the error message is incorrect: fancyMap is a type.

Apologies if there's an existing issue for this.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Dec 9, 2017

The error message is correct: at the point of the erroneous declaration, fancyMap refers to the function parameter, and that is not a type.

Any suggestions on what a more informative error message would look like?

@ianlancetaylor ianlancetaylor changed the title from "is not a type" error on variable/type name conflicts to cmd/compile: "is not a type" error on variable/type name conflicts Dec 9, 2017

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Dec 9, 2017

@cramertj

This comment has been minimized.

cramertj commented Dec 9, 2017

@ianlancetaylor Ah, I wasn't aware that variable bindings and types were intended to share the same namespace. In that case, perhaps issue a warning when a variable name shadows a type name or vice versa? If not that, then perhaps this specific error could be modified to look at the shadowed names and see if any of them is a type, and give an appropriate hint? I haven't looked at how Go's name resolution works, so I'm not sure how hard that would be in practice, but I'd be happy to try and put a PR together if one of these options sounds good to you.

@bradfitz

This comment has been minimized.

Member

bradfitz commented Dec 9, 2017

perhaps issue a warning

Go doesn't have any warnings, intentionally.

As stated in the FAQ:

There are two reasons for having no warnings. First, if it's worth complaining about, it's worth fixing in the code. (And if it's not worth fixing, it's not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.

@cramertj

This comment has been minimized.

cramertj commented Dec 9, 2017

@bradfitz I didn't mean to suggest some greater internal policy change-- do you have an alternative that you would prefer to see? Erroring on bindings-shadowing-types is obviously a breaking change and therefore a non-option. I suppose that leaves my second suggestion:

If not that, then perhaps this specific error could be modified to look at the shadowed names and see if any of them is a type, and give an appropriate hint?

@cramertj

This comment has been minimized.

cramertj commented Dec 9, 2017

I'd also be fine closing this as "WONTFIX" if you think such a change is unwanted.

@bradfitz bradfitz changed the title from cmd/compile: "is not a type" error on variable/type name conflicts to cmd/compile: more helpful "is not a type" error when variable shadows type Dec 9, 2017

@bradfitz bradfitz added the NeedsFix label Dec 9, 2017

@bradfitz

This comment has been minimized.

Member

bradfitz commented Dec 9, 2017

A better error sounds fine. Go does strive to have readable and helpful errors.

I've retitled and relabeled this bug. It's not targeted towards any release, meaning anybody can send a fix whenever.

@gopherbot

This comment has been minimized.

gopherbot commented Dec 17, 2017

Change https://golang.org/cl/84479 mentions this issue: cmd/compile: better "is not a type" error when parameter shadows type

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment