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.

Sign up for GitHub

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

cmd/compile: spurious "cannot infer T" type error #66842

Open
adonovan opened this issue Apr 15, 2024 · 1 comment
Open

cmd/compile: spurious "cannot infer T" type error #66842

adonovan opened this issue Apr 15, 2024 · 1 comment
Assignees
@griesemer
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. generics Issue is related to generics TypeInference Issue is related to generic type inference
Milestone
Go1.23

Comments

@adonovan
Copy link
Member

While working on https://go.dev/cl/578675, I noticed that some explicit type arguments were required in order to pacify the compiler---and also gopls' diagnostics, which run the go/types type checker. (Adding the explicit type arguments caused gopls' infertypeargs analyzer to tell me they were redundant, which I think they should be, but that's not what either go/types or go/types2 thinks.)

GOROOT @ 7418d41, x/tools @ cb134f5

xtools$ go build -o x ./gopls && echo PASS
PASS

Now apply this patch, which removes type arguments from the call to typesSeqToSlice:

xtools$ git diff
diff --git a/gopls/internal/golang/pkgdoc.go b/gopls/internal/golang/pkgdoc.go
index 2d3cdd02cb..2f1c78499f 100644
--- a/gopls/internal/golang/pkgdoc.go
+++ b/gopls/internal/golang/pkgdoc.go
@@ -492,10 +492,10 @@ window.onload = () => {
                if sig.Params().Len() > 3 {
                        sig = types.NewSignatureType(
                                sig.Recv(),
-                               typesSeqToSlice[*types.TypeParam](sig.RecvTypeParams()),
-                               typesSeqToSlice[*types.TypeParam](sig.TypeParams()),
+                               typesSeqToSlice(sig.RecvTypeParams()),
+                               typesSeqToSlice(sig.TypeParams()),
                                types.NewTuple(append(
-                                       typesSeqToSlice[*types.Var](sig.Params())[:3],
+                                       typesSeqToSlice(sig.Params())[:3],
                                        types.NewVar(0, nil, "", types.Typ[types.Invalid]))...),
                                sig.Results(),
                                sig.Variadic())
xtools$ go build -o x ./gopls || echo FAIL
# golang.org/x/tools/gopls/internal/golang
gopls/internal/golang/pkgdoc.go:495:21: in call to typesSeqToSlice, type *types.TypeParamList of sig.RecvTypeParams() does not match typesSeq[T] (cannot infer T)
gopls/internal/golang/pkgdoc.go:496:21: in call to typesSeqToSlice, type *types.TypeParamList of sig.TypeParams() does not match typesSeq[T] (cannot infer T)
gopls/internal/golang/pkgdoc.go:498:22: in call to typesSeqToSlice, type *types.Tuple of sig.Params() does not match typesSeq[T] (cannot infer T)
FAIL

typesSeqToSlice is defined thus:

type typesSeq[T any] interface {
	Len() int
	At(int) T
}

func typesSeqToSlice[T any](seq typesSeq[T]) []T {
	slice := make([]T, seq.Len())
	for i := range slice {
		slice[i] = seq.At(i)
	}
	return slice
}

Notably, its type parameters constrain only the results, not the arguments.

Strangely, the offending statement compiles just fine in the playground so I wonder whether the nested function context is confusing the type inference algorithm.
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Apr 15, 2024
@adonovan
Copy link
Member Author

Update: the nesting is irrelevant; the same thing happens when the statement is copied to a shallower function. The problem seems to be the go.work and go.mod file selecting an older version of the language semantics (1.19) that doesn't infer so well, even when running a newer toolchain.

So perhaps the real bug is in infertypeargs not honoring the per-file version semantics.

@ianlancetaylor ianlancetaylor added generics Issue is related to generics TypeInference Issue is related to generic type inference labels Apr 15, 2024
@mknyszek mknyszek added this to the Go1.23 milestone Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@griesemer griesemer

Labels
compiler/runtime Issues related to the Go compiler and/or runtime. generics Issue is related to generics TypeInference Issue is related to generic type inference
Projects
Go Compiler / Runtime
Status: Todo
Milestone
Go1.23
Development

No branches or pull requests
5 participants
@mknyszek @ianlancetaylor @adonovan @griesemer @gopherbot