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: better error message for scoped type error #15575

Open
gouthamve opened this Issue May 6, 2016 · 8 comments

Comments

Projects
None yet
8 participants
@gouthamve

gouthamve commented May 6, 2016

  1. What version of Go are you using (go version)?
    go version go1.6.2 darwin/amd64
  2. What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
  1. What did you do?
    https://play.golang.org/p/pJBsVvubBw
  2. What did you expect to see?
    An error message that was clear
  3. What did you see instead?
    Spent over an hour figuring out why type a was not taking type a

I think there should be a better error message for this case, as debugging it was super hard.

@bradfitz bradfitz changed the title from Better error message for scoped type error to cmd/compile: better error message for scoped type error May 6, 2016

@bradfitz bradfitz modified the milestones: Go1.7Maybe, Go1.8Maybe May 6, 2016

@bradfitz

This comment has been minimized.

Member

bradfitz commented May 6, 2016

/cc @mdempsky

@griesemer griesemer assigned griesemer and unassigned griesemer May 6, 2016

@griesemer

This comment has been minimized.

Contributor

griesemer commented May 6, 2016

It's not a common mistake: local types are rare, and local types named like outer types are even more rare, so I'd say there's no urgency on this.

That said, if we just say something like "type T (defined in F)" we could provide a very accurate message. Shouldn't be hard to do. It's a bit of a balance between precision of error and overly verbose error message.

@mdempsky

This comment has been minimized.

Member

mdempsky commented May 6, 2016

It's also possible (albeit increasingly unlikely) for multiple type Ts to be declared within a single function, so there may be cases where we want to disambiguate identically named types by line number instead: https://play.golang.org/p/zs6_-3awLP

@griesemer

This comment has been minimized.

Contributor

griesemer commented May 6, 2016

@mdempsky Indeed. It probably would be better to just report the line number (or file:line info). Needs a bit of experimentation for a pleasant result.

@quentinmit quentinmit added the NeedsFix label Oct 10, 2016

@rsc rsc modified the milestones: Go1.9, Go1.8Maybe Oct 20, 2016

@gopherbot

This comment has been minimized.

gopherbot commented May 4, 2017

CL https://golang.org/cl/42750 mentions this issue.

@mdempsky

This comment has been minimized.

Member

mdempsky commented May 8, 2017

CL 42750 adds support for line number disambiguation when using two different-but-identical-looking named types, but there are also cases where we have different-but-identical-looking anonymous types. For example:

func _() {
    var s []int
    type int uint
    var t []int = s
    _ = t
}

currently emits:

cannot use s (type []int) as type []int in assignment

And in general, there might be arbitrarily many different named types within the source and destination types (e.g., maps and structs)

Are we happy to only special case named types? Or any ideas how to explain to the user why "map[K]V" and "map[K]V" might be different types?

@tzneal

This comment has been minimized.

Member

tzneal commented May 9, 2017

I didn't think about that. It seems less likely to occur, but I don't like the inconsistency. Happy to abandon the CL.

@griesemer

This comment has been minimized.

Contributor

griesemer commented Jun 6, 2017

Not urgent. Moving to 1.10.

@griesemer griesemer modified the milestones: Go1.10, Go1.9 Jun 6, 2017

@bradfitz bradfitz modified the milestones: Go1.10, Go1.11 Nov 29, 2017

@griesemer griesemer modified the milestones: Go1.11, Unplanned Jun 5, 2018

@griesemer griesemer assigned griesemer and unassigned mdempsky Jun 5, 2018

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