-
Notifications
You must be signed in to change notification settings - Fork 18.1k
go/importer: receiver type of method of a named interface type loaded from exportdata is unnamed #13829
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
Labels
Milestone
Comments
(See Google internal issue 26331962.) |
See output of http://play.golang.org/p/WOgHkrUr16 (when run locally) for example:
|
Change https://golang.org/cl/85318 mentions this issue: |
Change https://golang.org/cl/118555 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Jun 13, 2018
…n in std lib This CL brings over the changes from: https://go-review.googlesource.com/118496 (better error message when importer is out of date) https://go-review.googlesource.com/114317 (permit embedding of non-defined interfaces via alias type names) https://go-review.googlesource.com/85318 (use named receiver types for methods of named interfaces) https://go-review.googlesource.com/42870 (report import path if package is not found) https://go-review.googlesource.com/41710 (version tests for 1.8, v4 and v5) Also updated go/gcexportdata to select between binary and new indexed export format. For golang/go#25856. For golang/go#25301. For golang/go#20230. For golang/go#13829. Change-Id: Ibf77c50f86e767cef411bd1d3809e12397678958 Reviewed-on: https://go-review.googlesource.com/118555 Run-TryBot: Robert Griesemer <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Alan Donovan <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It would be convenient for tools if the receiver of a named interface type had the named type, instead of a copy of the underlying type, which is unwieldy and loses information. There's an existing TODO in
types.NewInterface
to this effect.This feature could be supported in a backward-compatible way by adding a
SetReceiver(*types.TypeName)
method to*types.Interface
.The text was updated successfully, but these errors were encountered: