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: unhelpful error message if type assertion has mismatching pointer/non-pointer type #43673
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
help wanted
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Comments
howjmay
added a commit
to howjmay/go
that referenced
this issue
Jan 21, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type. close golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Jan 21, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type. close golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Jan 21, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type. close golang#43673
Change https://golang.org/cl/285372 mentions this issue: |
I have opened a PR to revise the error message. Please take a look. Thank you so much. |
howjmay
added a commit
to howjmay/go
that referenced
this issue
Jan 22, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type. close golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Jan 23, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type. close golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Jan 23, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type. This adds a better error hint for the situation that a user writes x.(*I), but they meant to write x.(I). Fixes golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Jan 23, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type. This adds a better error hint for the situation that a user writes x.(*I), but they meant to write x.(I). Fixes golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Jan 24, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type. This adds a better error hint for the situation that a user writes x.(*I), but they meant to write x.(I). Fixes golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Feb 3, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type, which means this PR adds a better error hint for the situation that a user writes x.(*I), but they meant to write x.(I). In this situation, compiler would check out whether the the missing methods are implemented by the dereferenced object. If the dereferenced object implements these missing methods, then return error message `<original_object> does not have <missing_method> (but <dereferenced_object> does)` Fixes golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Feb 4, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type, which means this PR adds a better error hint for the situation that a user writes x.(*I), but they meant to write x.(I). In this situation, compiler would check out whether the the missing methods are implemented by the dereferenced object. If the dereferenced object implements these missing methods, then return error message `<original_object> does not have <missing_method> (but <dereferenced_object> does)` Fixes golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Feb 4, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type, which means this PR adds a better error hint for the situation that a user writes x.(*I), but they meant to write x.(I). In this situation, compiler would check out whether the the missing methods are implemented by the dereferenced object. If the dereferenced object implements these missing methods, then return error message `<original_object> does not have <missing_method> (but <dereferenced_object> does)` Fixes golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Feb 5, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type, which means this PR adds a better error hint for the situation that a user writes x.(*I), but they meant to write x.(I). In this situation, compiler would check out whether the the missing methods are implemented by the dereferenced object. If the dereferenced object implements these missing methods, then return error message `<original_object> does not have <missing_method> (but <dereferenced_object> does)` Fixes golang#43673
howjmay
added a commit
to howjmay/go
that referenced
this issue
Apr 11, 2021
Revise the error message under the condition that type assertion has mismatching pointer/non-pointer type, which means this PR adds a better error hint for the situation that a user writes x.(*I), but they meant to write x.(I). In this situation, compiler would check out whether the the missing methods are implemented by the dereferenced object. If the dereferenced object implements these missing methods, then return error message `<original_object> does not have <missing_method> (but <dereferenced_object> does)` Fixes golang#43673
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
help wanted
NeedsFix
The path to resolution is known, but the work has not been done.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?n/a
What did you do?
This code:
Complains:
The issue is that you need to write
err.(FooError)
.What did you expect to see?
It'd be much more helpful if it'd call out that
FooError
does implement error, so the problem is the added pointer indirection.This mistake is likely because usually the concrete struct types implement error via the pointer reference, so if you change code from the concrete struct error to an interface type, you're likely to miss a
*
in there.What did you see instead?
The error message above.
The text was updated successfully, but these errors were encountered: