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: better error messages from types2 (Go 1.18) for unexported fields/methods #49736

Open
danscales opened this issue Nov 22, 2021 · 4 comments
Assignees
Milestone

Comments

@danscales
Copy link

@danscales danscales commented Nov 22, 2021

The error messages from types2 for Go 1.18, I think, as less helpful than the Go 1.17 (-G=0) messages in the case of unexported fields and members. This is shown for the two existing bug test cases in go/test/fixedbugs, issue18419.go and issue31053.go.

We have disabled these tests in run.go because of different error message output for Go 1.17 and Go.18, and the difference is because Go 1.18 is not helpfully indicating the problem is due to an unexported field/method, but is instead indicating the field/method is unknown or doesn't exist.
(I'm going through a bunch of the other disabled tests, which are mostly due to largely equivalent error messages, just slight different words or a few extra, related errors. One area that I will work on fixing is missing errors because of improper compiler directives (//go:...), which are mostly ignored by types2.)

You can enable the test for each of these issues by commenting out the specified issue in types2Failures array in test/run.go.

For issue 18419, the Go 1.17 error message is:

./test.go:12:3: e.member undefined (cannot refer to unexported field or method member)

whereas for Go 1.18 it is:

./test.go:12:4: e.member undefined (type *other.Exported has no field or method member, but does have Member)

For issue 31053, there are many error messages that match, but the two relevant ones that differ are for Go 1.17:

./p.go:13:3: cannot refer to unexported field 'doneChan' in struct literal of type f1.Foo
./p.go:20:3: cannot refer to unexported field 'hook' in struct literal of type f1.Foo

and for Go 1.18:

./p.go:13:3: unknown field 'doneChan' in struct literal of type f1.Foo
./p.go:20:3: unknown field 'hook' in struct literal of type f1.Foo

If it makes sense to fix, I'm sure this is fine to fix either before or after the beta release.

@griesemer @findleyr

@danscales danscales added this to the Go1.18 milestone Nov 22, 2021
@griesemer griesemer self-assigned this Nov 22, 2021
@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 22, 2021

For issue 18419, the error message is longer in 1.18 but provide equal if not more information.
For issue 31053, the two messages that are different should probably be fixed.

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 22, 2021

cc: @findleyr

Loading

@findleyr
Copy link
Contributor

@findleyr findleyr commented Nov 22, 2021

For issue 18419, the error message is longer in 1.18 but provide equal if not more information.

I don't think that's entirely true. Exported has both member and Member. The 1.17 message points out the unexported member, the 1.18 message points out the exported Member. Both are useful, but this from the 1.18 error message seems a little misleading: *other.Exported has no field or method member.

Loading

@danscales
Copy link
Author

@danscales danscales commented Nov 22, 2021

Yes, I agree on 18419 - the message is factually incorrect. In both cases, essentially types2 is not noting that the real problem is that the available field/method is not exported, so can't be used. (I guess in issue 18419, you could argue that the more likely error the user is making is not calling the upper-case Member, as opposed to the lower-case member (which is a field), though hard to guess the user's intent.)

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants