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, types2: broken invariants with respect to generic receiver types #50619

Open
findleyr opened this issue Jan 14, 2022 · 1 comment
Open

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Jan 14, 2022

Our handling of receiver type on generic methods in go/types and types2 is confusing, and arguably incorrect.

While type checking method declarations, the type checker checks the receiver expression T[P1,...PN], resulting in a receiver type that is instantiated with its receiver type parameters, and then assigns this receiver type to the signature being type-checker. This has two surprising consequences:

  1. The receiver type of methods on a generic type is not itself generic: it is instantiated with receiver type parameters.
  2. Because the receiver type is treated as an instance, it is recorded in the Info.Instances map, and its methods are subsequently re-substituted. This means that the defined method F (the thing in Info.Defs!) is not contained in the method set of F.Type().(*types.Signature).Recv().Type()!

Of these, I think (1) is a perhaps peculiar choice that we must stick with, and (2) is a bug -- a consequence of our choice to treat the receiver as an instance and a later decision to instantiate methods on instances. I think this is probably not that difficult to fix: we should avoid naively type checking the receiver parameter list. It is certainly a release blocker to decide what to do here.

@griesemer, do you agree?

CC @timothy-king, who encountered this while working on go/ssa.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jan 15, 2022

Per virtual in-person discussion, I agree that we need to address this. The receiver type handling is a historical accident: before generics, the most expedient way to type-check a method signature was to treat the receiver parameter list just like any other parameter list.

This didn't work anymore for parameterized method receiver types because they look like an instantiated type - yet they are really declaring their own type parameters. Rather than completely changing the original code, I added some pre-amble to extract and declare those type parameters beforehand, so that the receiver type could be type-checked as an instantiated type (and the rest of the code didn't need to change). That code was pretty simple originally, but over time has become more and more complex, with unintended side effects (like what we're observing now). In retrospect, it would have been better to treat receiver parameter lists specially from the start (at least if they have a generic receiver).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants