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

cmd/compile: function parameter order-dependence in type inference #60946

Closed
griesemer opened this issue Jun 22, 2023 · 3 comments
Closed

cmd/compile: function parameter order-dependence in type inference #60946

griesemer opened this issue Jun 22, 2023 · 3 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. release-blocker
Milestone

Comments

@griesemer
Copy link
Contributor

griesemer commented Jun 22, 2023

Type inference is supposed to be function parameter order independent. Here's a counter-example (playground):

package main

func main() {
	var t T
	var t1 *T1
	var t2 *T2
	g(t, t1, t2) // this works
	g(t1, t2, t) // this doesn't
}

type T interface{ m() }
type T1 struct{}
type T2 struct{}

func (*T1) m() {}
func (*T2) m() {}

func g[P any](...P) {}

Analysis: In the call g(t1, t2, t), the first two arguments (t1, t2) have types that don't match and unification fails. In the call g(t, t1, t2), the argument t subsumes the other types and it works out.

This issue also arises if the interface T were an unnamed interface.

Tentatively marking as a release blocker.

@griesemer griesemer added NeedsFix The path to resolution is known, but the work has not been done. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. release-blocker labels Jun 22, 2023
@griesemer griesemer added this to the Go1.21 milestone Jun 22, 2023
@griesemer griesemer self-assigned this Jun 22, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jun 22, 2023
@griesemer
Copy link
Contributor Author

See also #60933.

@gopherbot gopherbot removed the NeedsFix The path to resolution is known, but the work has not been done. label Jun 22, 2023
@gopherbot
Copy link

Change https://go.dev/cl/505396 mentions this issue: go/types, types2: fix interface inference

@gopherbot
Copy link

Change https://go.dev/cl/506396 mentions this issue: go/types, types2: simpler fix for interface unification

bradfitz pushed a commit to tailscale/go that referenced this issue Jul 15, 2023
When unification of two types succeeds and at least one of them
is an interface, we must be more cautious about when to accept
the unification, to avoid order dependencies and unexpected
inference results.

The changes are localized and only affect matching against
interfaces; they further restrict what are valid unifications
(rather than allowing more code to pass). We may be able to
remove some of the restriotions in a future release.

See comments in code for a detailed description of the changes.

Also, factored out "asInterface" functionality into a function
to avoid needless repetition in the code.

Fixes golang#60933.
Fixes golang#60946.

Change-Id: I923f7a7c1a22e0f4fd29e441e016e7154429fc5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/505396
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. release-blocker
Projects
None yet
Development

No branches or pull requests

2 participants