-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: interface conversion error lost method details #48471
Comments
See also #48472. |
Change https://golang.org/cl/350697 mentions this issue: |
One suggestion I made in #48472 which I think is worth considering as a possibility: I would almost always like to see a list of all the missing methods when some aren't implemented. That not only gives more context for the error, but also saves repeated compile cycles when filling out several required methods. If there are really many methods, we could truncate at 5 or so - usually it's only 2 or 3 in my experience. |
Printing more than one sounds fine too. Just more than zero! |
I tried to build with https://golang.org/cl/350697 to debug a problem I have with generics, and found that |
Ping -- how's the CL going? |
We'll need to spend some time fine-tuning error messages. At the moment we have higher-priority items to work on. |
Thanks for point me here @ericlagergren from #48833! I implemented the prior diagnostics in Go1.8 or so, so looks like it is time for me to roll up my sleeves one of these days. |
I've started working on this, to take off some load from Robert. |
Change https://golang.org/cl/363437 mentions this issue: |
Change https://golang.org/cl/363436 mentions this issue: |
When being used by the compiler, fix up types2 error messages to be more like Go 1.17 compiler errors. In particular: - add information about which method is missing when a type is not assignable/convertible/etc. to an interface. - add information about any existing method which has the same name, but wrong type. - add extra hint in the case that the source or destination type is a pointer to an interface, rather than an interface. - add extra hint "need type assertion" in the case that the source is an interface that is implemented by the destination. - the following change in the CL stack also adds information about any existing method with a different name that only differs in case. Include much of the new logic in a new common function (*Checker).missingMethodReason(). types2 still adds a little more information in some cases then the Go 1.17 compiler. For example, it typically says "(value of type T)", rather than "(type T)", where "value" could also be "constant", "variable", etc. I kept the types2 error messages almost all the same when types2 is not used by the compiler. The only change (to reduce amount of compatibility code) was to change "M method" phrasing in one case to "method M" phrasing in one error message (which is the phrasing it uses in all other cases). That is the reason that there are a few small changes in types2/testdata/check/*.src. Added new test test/fixedbugs/issue48471.go to test that the added information is appearing correctly. Also adjusted the pattern matching in a bunch of other test/fixedbugs/*.go, now that types2 is producing error messages closer to Go 1.17. Was able to remove a couple test files from the types2 exception list in run.go. Updated #48471 Change-Id: I8af1eae6eb8a5541d8ea20b66f494e2e795e1956 Reviewed-on: https://go-review.googlesource.com/c/go/+/363436 Trust: Dan Scales <[email protected]> Run-TryBot: Dan Scales <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Robert Griesemer <[email protected]>
The new type checker no longer explains interface satisfaction errors during assignment and type assertion failures by saying what method is missing, nor by showing when signatures differ, nor by showing when methods are available that differ only in case. The messages also omit the context - "in argument to f", "in assignment" and so on. These also make the errors much easier to understand, especially in implicit conversions such as function argument assignment. (The fine-grained position information might provide similar precision, but it requires tool support or character counting for humans to use.)
These are all critical aids when writing Go code, which we have spent years refining and making useful. They are a key part of why people say Go has understandable error messages.
Note in the transcript below that the impossible type assertion does include the information in the signature mismatch case, but formatted in a single line, making it harder to compare. Please restore the old multiline format, which is more readable for people because the two things being compared are lined up one right below the other.
These details need to be ported forward to the new type checker before the Go 1.18 release.
The specific logic for the old errors is in cmd/compile/internal/typecheck's Assignop and tcDotType.
/cc @griesemer @findleyr
The text was updated successfully, but these errors were encountered: