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
go/types: remove temp. work-around for issue 26390 #26854
Comments
Related: #23203 |
Change https://golang.org/cl/128435 mentions this issue: |
Because methods are type-checked before the receiver base type is "complete" (i.e., they are checked as part of the receiver base type), situations occur where aliases of those base types are used (in those methods) but the alias types are not known yet (even though their base types are known). This fix is a temporary work-around that looks syntactically for the base types of alias types and uses those base types when we refer to an "incomplete" alias type. The work-around is completely localized and guarded with a flag so it can be disabled at short notice. The correct fix (slated for 1.12) is to decouple type-checking of methods from their receiver base types. See issue #26854. Fixes #26390. Change-Id: I66cc9d834b220c254ac00e671a137cf8a3da59c1 Reviewed-on: https://go-review.googlesource.com/128435 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Change https://golang.org/cl/139422 mentions this issue: |
LookupFieldOrMethod needs to know if a method receiver is a pointer type. Until now this was computed from the the method signature's receiver, which required the method signature to be type-checked. Furthermore, it required the receiver to be set before the method signature was fully type-checked in some cases (see issue #6638). This CL remembers this property during object resolution, when we know it from the source. With this CL, method signatures don't need to be type-checked before they can be looked up; this is a first step towards separating type checking of types and type-checking of associated methods. Updates #23203. Updates #26854. Change-Id: Ie3eb7976e8fe8176ea1b284fa7471a4b7000f80b Reviewed-on: https://go-review.googlesource.com/c/139422 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Change https://golang.org/cl/139897 mentions this issue: |
Change https://golang.org/cl/139721 mentions this issue: |
Change https://golang.org/cl/139425 mentions this issue: |
Change https://golang.org/cl/139899 mentions this issue: |
Change https://golang.org/cl/139900 mentions this issue: |
The prior CL prepared go/types for the situation where methods might not have a type-checked signature when being looked up. The respective adjustments to recvPtr were not correct (but because so far method signatures are type-checked in time, the bug didn't manifest itself). Updates #23203. Updates #26854. Change-Id: I796691d11e6aac84396bdef802ad30715755fcc6 Reviewed-on: https://go-review.googlesource.com/c/139721 Reviewed-by: Alan Donovan <adonovan@google.com>
…re used Remove assumption that methods associated to concrete (non-interface) types have a fully set up signature. Such methods are found through LookupFieldOrMethod or lookupMethod, or indexed method access from a Named type. Make sure that the method's signature is type-checked before use in those cases. (MethodSets also hold methods but the type checker is not using them but for internal verification. API clients will be using it after all methods have been type-checked.) Some functions such as MissingMethod may now have to type-check a method and for that they need a *Checker. Add helper functions as necessary to provide the additional (receiver) parameter but permit it to be nil if the respective functions are invoked through the API (at which point we know that all methods have a proper signature and thus we don't need the delayed type-check). Since all package-level objects eventually are type-checked through the top-level loop in Checker.packageObjects we are guaranteed that all methods will be type-checked as well. Updates #23203. Updates #26854. Change-Id: I6e48f0016cefd498aa70b776e84a48215a9042c5 Reviewed-on: https://go-review.googlesource.com/c/139425 Reviewed-by: Alan Donovan <adonovan@google.com>
As a side-effect we also get slightly clearer errors for some pathological cyclic method declarations. Fixes #23203. Updates #26854. Change-Id: I30bd6634ac6be26d3f4ef8c7b32e5c1bf76987dd Reviewed-on: https://go-review.googlesource.com/c/139897 Reviewed-by: Alan Donovan <adonovan@google.com>
Reminder issue.
Remove the code around flag
fixFor26390
indecl.go
in favor of separate type-checking of receiver base types and their associated methods.The text was updated successfully, but these errors were encountered: