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: type inference fails when a prefix of type arguments is provided #44799

Closed
griesemer opened this issue Mar 5, 2021 · 5 comments
Closed

go/types, types2: type inference fails when a prefix of type arguments is provided #44799

griesemer opened this issue Mar 5, 2021 · 5 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.17

Comments

@griesemer
Copy link
Contributor

Given program

package main

func Map[F, T any](s []F, f func(F) T) []T { return nil }

func Reduce[Elem1, Elem2 any](s []Elem1, initializer Elem2, f func(Elem2, Elem1) Elem2) Elem2 { var x Elem2; return x }

func main() {
	var s []int
	var f1 func(int) float64
	var f2 func(float64, int) float64
	//_ = Map[int](s, f1)       // <<< this should work, too
	_ = Map(s, f1)
	//_ = Reduce[int](s, 0, f2) // <<< this should work, too
	_ = Reduce(s, 0, f2)
}

Type inference fails for the commented out statements. It should work.

cc: @findleyr
@griesemer griesemer added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 5, 2021
@griesemer griesemer added this to the Go1.17 milestone Mar 5, 2021
@griesemer griesemer self-assigned this Mar 5, 2021
@findleyr
Copy link
Contributor

findleyr commented Mar 5, 2021

The problem is that we don't continue with normal inference if constraint type inference fails. I suspect this bug that was introduced when we extracted logic out of Checker.call into Checker.funcInst -- now when checking a call we check the call.Fun independently.

I'll try to fix.

@findleyr findleyr self-assigned this Mar 5, 2021
@griesemer
Copy link
Contributor Author

The order needs to be:

  • start with whatever type arguments are provided
  • use function type inference (using the actual function arguments) to infer more type arguments (if we have an actual call_
  • use constraint type inference if we still have missing type arguments

@gopherbot
Copy link

Change https://golang.org/cl/299829 mentions this issue: go/types: try function type inference before constraint type inference

@gopherbot
Copy link

Change https://golang.org/cl/308372 mentions this issue: cmd/compile/internal/types2: use combined type and ordinary args for type inference

@gopherbot
Copy link

Change https://golang.org/cl/308973 mentions this issue: cmd/compile/internal/types: add example test for type inference

gopherbot pushed a commit that referenced this issue Apr 13, 2021
@griesemer
cmd/compile/internal/types: add example test for type inference
39dd96c 
Follow-up on https://golang.org/cl/308372.

For #44799.

Change-Id: I27d149241d465ee31e9c21d5f0935f31efcb5b60
Reviewed-on: https://go-review.googlesource.com/c/go/+/308973
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@golang golang locked and limited conversation to collaborators Apr 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.17
Development

No branches or pull requests
3 participants
@griesemer @gopherbot @findleyr