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

Jump to bottom

go/types, types2: simplify type-checking of method receivers with type parameters #51343

Open
griesemer opened this issue Feb 24, 2022 · 8 comments
Open

go/types, types2: simplify type-checking of method receivers with type parameters #51343

griesemer opened this issue Feb 24, 2022 · 8 comments
Assignees
@griesemer
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.23

Comments

@griesemer
Copy link
Contributor

This is a reminder issue to clean up handling of method receivers in Checker.funcType.
Receiver parameter handling relies on delayed instantiation and uses constraint type inference. At least the latter should not be used.
See also #51339.

cc: @findleyr
@griesemer griesemer added NeedsFix The path to resolution is known, but the work has not been done. early-in-cycle A change that should be done early in the 3 month dev cycle. labels Feb 24, 2022
@griesemer griesemer added this to the Go1.19 milestone Feb 24, 2022
@griesemer griesemer self-assigned this Feb 24, 2022
@gopherbot
Copy link

Change https://go.dev/cl/387836 mentions this issue: types2: method recv type parameter count must match base type parameter count

gopherbot pushed a commit that referenced this issue Feb 24, 2022
@griesemer
go/types, types2: method recv type parameter count must match base ty…
c0840a7 
…pe parameter count

Check receiver type parameter count when type checking the method
signature and report a suitable error (don't rely on delayed
instantiation and possibly constraint type inference).

While at it, simplify blank name recoding and type bound rewriting.

Stop-gap measure to avoid crashes in the compiler.

Fixes #51339.
For #51343.

Change-Id: Idbe2d32d69b66573ca973339f8924b349d2bc9cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/387836
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link

This issue is currently labeled as early-in-cycle for Go 1.19.
That time is now, so a friendly reminder to look at it again.

@griesemer griesemer modified the milestones: Go1.19, Go1.20 Jun 7, 2022
@griesemer griesemer mentioned this issue Jun 13, 2022
Open
@gopherbot
Copy link

This issue is currently labeled as early-in-cycle for Go 1.20.
That time is now, so a friendly reminder to look at it again.

@griesemer griesemer modified the milestones: Go1.20, Go1.21 Nov 15, 2022
@gopherbot
Copy link

This issue is currently labeled as early-in-cycle for Go 1.21.
That time is now, so a friendly reminder to look at it again.

@griesemer
Copy link
Contributor Author

Too late again for 1.21. Moving to 1.22.

@griesemer griesemer modified the milestones: Go1.21, Go1.22 May 25, 2023
@gopherbot
Copy link

This issue is currently labeled as early-in-cycle for Go 1.22.
That time is now, so a friendly reminder to look at it again.

@griesemer
Copy link
Contributor Author

Moving to 1.22. We didn't get to this.

@griesemer griesemer modified the milestones: Go1.22, Go1.23 Nov 7, 2023
@gopherbot
Copy link

This issue is currently labeled as early-in-cycle for Go 1.23.
That time is now, so a friendly reminder to look at it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@griesemer griesemer

Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. NeedsFix The path to resolution is known, but the work has not been done.
Projects
Go Compiler / Runtime
Status: Todo
Milestone
Go1.23
Development

No branches or pull requests
2 participants
@griesemer @gopherbot