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

go/types: remove temp. work-around for issue 26390 #26854

Closed
griesemer opened this issue Aug 8, 2018 · 8 comments
Closed

go/types: remove temp. work-around for issue 26390 #26854

griesemer opened this issue Aug 8, 2018 · 8 comments

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Aug 8, 2018

Reminder issue.

Remove the code around flag fixFor26390 in decl.go in favor of separate type-checking of receiver base types and their associated methods.

@griesemer griesemer self-assigned this Aug 8, 2018
@griesemer griesemer added this to the Go1.12 milestone Aug 8, 2018
@griesemer
Copy link
Contributor Author

@griesemer griesemer commented Aug 8, 2018

Related: #23203

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 8, 2018

Change https://golang.org/cl/128435 mentions this issue: go/types: if base type for an alias is known, use it when needed

Loading

gopherbot pushed a commit that referenced this issue Aug 8, 2018
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>
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 3, 2018

Change https://golang.org/cl/139422 mentions this issue: go/types: determine hasPtrRecv property from source rather than type

Loading

gopherbot pushed a commit that referenced this issue Oct 4, 2018
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>
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 4, 2018

Change https://golang.org/cl/139897 mentions this issue: go/types: don't type-check method signatures eagerly anymore

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 4, 2018

Change https://golang.org/cl/139721 mentions this issue: go/types: fix recvPtr helper (follow-up on https://golang.org/cl/139422)

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 4, 2018

Change https://golang.org/cl/139425 mentions this issue: go/types: prepare for delayed type-checking of methods to when they are used

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 4, 2018

Change https://golang.org/cl/139899 mentions this issue: go/types: remove work-around for issue #26390

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 5, 2018

Change https://golang.org/cl/139900 mentions this issue: go/types: remove work-around for issue #26390

Loading

gopherbot pushed a commit that referenced this issue Oct 5, 2018
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>
gopherbot pushed a commit that referenced this issue Oct 5, 2018
…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>
gopherbot pushed a commit that referenced this issue Oct 5, 2018
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>
@gopherbot gopherbot closed this in 71d40c4 Oct 5, 2018
@golang golang locked and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants