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

Jump to bottom

cmd/compile: more helpful "is not a type" error when variable shadows type #23065

Open
cramertj opened this issue Dec 9, 2017 · 8 comments
Open

cmd/compile: more helpful "is not a type" error when variable shadows type #23065

cramertj opened this issue Dec 9, 2017 · 8 comments
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unplanned

Comments

@cramertj
Copy link

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

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 "is not a type" error on variable/type name conflicts 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
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 9, 2017
@cramertj
Copy link
Author

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

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

cramertj commented Dec 9, 2017 •
edited

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

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 cmd/compile: "is not a type" error on variable/type name conflicts cmd/compile: more helpful "is not a type" error when variable shadows type Dec 9, 2017
@bradfitz bradfitz added the NeedsFix The path to resolution is known, but the work has not been done. label Dec 9, 2017
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 9, 2017
@bradfitz bradfitz added help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 9, 2017
@bradfitz
Copy link
Contributor

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

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

@mvdan mvdan mentioned this issue Jul 23, 2018
Closed
@gopherbot
Copy link

Change https://golang.org/cl/172357 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
Assignees
No one assigned
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@bradfitz @ianlancetaylor @cramertj @gopherbot