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: using unexported identifier causes case mismatch suggestion #25727

Closed
willfaught opened this issue Jun 4, 2018 · 6 comments
Closed

cmd/compile: using unexported identifier causes case mismatch suggestion #25727

willfaught opened this issue Jun 4, 2018 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.12

Comments

@willfaught
Copy link
Contributor

Sorry if this is a dupe. GitHub phrase searches for "unknown field" or "but does have" seem to not return exact matches right now.

What did you do?

https://play.golang.org/p/Kk_EIikQW8M

var _ = http.Server{doneChan: nil}

What did you expect to see?

prog.go:8:30: unknown field 'doneChan' in struct literal of type http.Server

What did you see instead?

prog.go:8:30: unknown field 'doneChan' in struct literal of type http.Server (but does have http.doneChan)

This seems to be hitting code that mistakenly thinks there's a case mismatch, where I typed "doneChan" but really meant "DoneChan", or vice versa. This was very confusing and took about 10 minutes to understand (in a more complex context on my machine).
@fraenkel
Copy link
Contributor

fraenkel commented Jun 5, 2018

Why? http.Server does have a doneChan.

@willfaught
Copy link
Contributor Author

Are you asking why the error message wrong? It's wrong because:

  • Server is in a different package, and I tried to use its unexported "doneChan" field, and there's no exported "DoneChan" field, so trying to use doneChan is clearly wrong, with no possible alternative field worth suggesting. It should just say that there isn't a doneChan field.
  • but does have http.doneChan makes no sense: doneChan isn't a package-scope var in package http; if anything, it should be but does have http.Server.doneChan

@FiloSottile
Copy link
Contributor

A couple variations:

https://play.golang.org/p/eDHDcSIeCGa

s := http.Server{}
_ = s.DoneChan

s.DoneChan undefined (type http.Server has no field or method DoneChan, but does have http.doneChan) (also wrong)

s := http.Server{}
_ = s.doneChan

s.doneChan undefined (cannot refer to unexported field or method doneChan) (correct)

/cc @odeke-em @dr2chase

@FiloSottile FiloSottile changed the title compiler: using unexported identifier causes case mismatch suggestion cmd/compile: using unexported identifier causes case mismatch suggestion Jun 5, 2018
@FiloSottile FiloSottile added the NeedsFix The path to resolution is known, but the work has not been done. label Jun 5, 2018
@FiloSottile FiloSottile added this to the Go1.11 milestone Jun 5, 2018
@griesemer
Copy link
Contributor

Not urgent.

@griesemer griesemer modified the milestones: Go1.11, Go1.12 Jun 5, 2018
@gopherbot
Copy link

Change https://golang.org/cl/117755 mentions this issue: cmd/compile: make case insensitive suggestions aware of package

@odeke-em
Copy link
Member

Thank you for the report @willfaught, thank you for the investigation and ping @FiloSottile and thanks @fraenkel and @griesemer for taking a look too.

I hadn't seen, I've been quite swamped but I just got a chance to take a look at it and I've mailed a CL, PTAL.

@odeke-em odeke-em self-assigned this Jun 11, 2018
dna2github pushed a commit to dna2fork/go that referenced this issue Jun 14, 2018
@odeke-em @dna2github
cmd/compile: make case insensitive suggestions aware of package
dd1f7b7 
Ensure that compiler error suggestions after case insensitive
field lookups don't mistakenly reported unexported fields if
those fields aren't in the local package being processed.

Fixes golang#25727

Change-Id: Icae84388c2a82c8cb539f3d43ad348f50a644caa
Reviewed-on: https://go-review.googlesource.com/117755
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@cben cben mentioned this issue Mar 26, 2019
Closed
@golang golang locked and limited conversation to collaborators Jun 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.12
Development

No branches or pull requests
6 participants
@willfaught @fraenkel @FiloSottile @odeke-em @griesemer @gopherbot