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.
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.
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.)