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: incorrect "cannot use .this" error when using _ for multiple type parameters in method declaration #50419

Closed
samherrmann opened this issue Jan 4, 2022 · 4 comments
Closed

cmd/compile: incorrect "cannot use .this" error when using _ for multiple type parameters in method declaration #50419

samherrmann opened this issue Jan 4, 2022 · 4 comments
Labels
FrozenDueToAge
Milestone
Go1.18

Comments

@samherrmann
Copy link

What version of Go are you using (go version)?

$ go version
go version go1.18beta1 linux/amd64

Does this issue reproduce with the latest release?

N/A. Type parameters are not available in any other version that are currently available.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOVERSION="go1.18beta1"

What did you do?

package main

import (
    "fmt"
)

func main() {
    foo := &Foo[string, int]{
        valueA: "i am a string",
        valueB: 123,
    }
    fmt.Println(foo)
}

type Foo[T1 any, T2 any] struct {
    valueA T1
    valueB T2
}

func (f *Foo[_,_]) String() string {
    return fmt.Sprintf("%v %v", f.valueA, f.valueB)
}

What did you expect to see?

I expected the code snippet above to build and run successfully.

What did you see instead?

Build error:

<autogenerated>:1: cannot use .this (type *Foo[string,int]) as type *Foo[go.shape.string_0,go.shape.string_0] in argument to (*Foo[go.shape.string_0,go.shape.int_1]).String
@danscales
Copy link
Contributor

danscales commented Jan 4, 2022 •
edited

Thanks for the issue report!

This is a problem in the main compiler (not the types2 typechecker). It happens when generating method wrappers. It looks like the use of [_, _] in func (f *Foo[_, _]) String() string { is causing the bug - we are somehow interpreting the blanks as the same type. Works fine if you just replace [_, _] with [T1, T2].

@danscales danscales changed the title build: Cannot use .this error when using _ for multiple type parameters in method declaration cmd/compile: incorrect "cannot use .this" error when using _ for multiple type parameters in method declaration Jan 4, 2022
@danscales danscales self-assigned this Jan 4, 2022
@danscales danscales added this to the Go1.18 milestone Jan 4, 2022
@gopherbot
Copy link

Change https://golang.org/cl/375474 mentions this issue: cmd/compile: make sure multiple blanks typeparams are still unique

@gopherbot
Copy link

Change https://golang.org/cl/375641 mentions this issue: go/internal/gcimporter: don't add blank type parameters to tparamIndex

@findleyr findleyr mentioned this issue Jan 6, 2022
Closed
@cuonglm cuonglm mentioned this issue Jan 7, 2022
Closed
@gopherbot
Copy link

Change https://golang.org/cl/379194 mentions this issue: cmd/compile: make sure multiple blanks typeparams are still unique

jproberts pushed a commit to jproberts/go that referenced this issue Jun 21, 2022
@danscales @jproberts
cmd/compile: make sure multiple blank typeparams remain unique
5eec393 
In a method declaration "func (f *Foo[_, _]) String() string { ... }",
the two blank typeparams have the same name, but our current design with
types1 needs unique names for type params. Similarly, for export/import,
we need unique names to keep the type params straight in generic types
and connect the proper type param with the proper constraint. We make
blank type params unique by changing them to $1, $2, etc in noder.typ0()
via typecheck.TparamExportName(). We then revert $<num> back to _ during
type2 import via typecheck.TparamName(). We similarly revert
during gcimporter import. We don't need/want to revert in the types1
importer, since we want unique names for type params.

Rob Findley has made a similar change to x/tools (and we tried to make
the source code changes similar for the gcimporter and types2 importer
changes).

Fixes golang#50419

Change-Id: I855cc3d90d06bcf59541ed0c879e9a0e4ede45bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/379194
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
@golang golang locked and limited conversation to collaborators Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
3 participants
@danscales @samherrmann @gopherbot