go/test/typeparam/boundmethod.go

107 lines
2.5 KiB
Go
Raw Normal View History

[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
// run -gcflags=-G=3
// Copyright 2021 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// This test illustrates how a type bound method (String below) can be implemented
// either by a concrete type (myint below) or a instantiated generic type
// (StringInt[myint] below).
package main
import (
"fmt"
"reflect"
"strconv"
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
)
type myint int
//go:noinline
func (m myint) String() string {
return strconv.Itoa(int(m))
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
}
type Stringer interface {
String() string
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
}
func stringify[T Stringer](s []T) (ret []string) {
for _, v := range s {
// Test normal bounds method call on type param
x1 := v.String()
// Test converting type param to its bound interface first
v1 := Stringer(v)
x2 := v1.String()
// Test method expression with type param type
f1 := T.String
x3 := f1(v)
// Test creating and calling closure equivalent to the method expression
f2 := func(v1 T) string {
return Stringer(v1).String()
}
x4 := f2(v)
if x1 != x2 || x2 != x3 || x3 != x4 {
panic(fmt.Sprintf("Mismatched values %v, %v, %v, %v\n", x1, x2, x3, x4))
}
ret = append(ret, v.String())
}
return ret
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
}
type Ints interface {
~int32 | ~int
}
type StringInt[T Ints] T
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
//go:noinline
func (m StringInt[T]) String() string {
return strconv.Itoa(int(m))
}
type StringStruct[T Ints] struct {
f T
}
func (m StringStruct[T]) String() string {
return strconv.Itoa(int(m.f))
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
}
func main() {
x := []myint{myint(1), myint(2), myint(3)}
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
// stringify on a normal type, whose bound method is associated with the base type.
got := stringify(x)
want := []string{"1", "2", "3"}
if !reflect.DeepEqual(got, want) {
panic(fmt.Sprintf("got %s, want %s", got, want))
}
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
x2 := []StringInt[myint]{StringInt[myint](5), StringInt[myint](7), StringInt[myint](6)}
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
// stringify on an instantiated type, whose bound method is associated with
// the generic type StringInt[T], which maps directly to T.
got2 := stringify(x2)
want2 := []string{ "5", "7", "6" }
if !reflect.DeepEqual(got2, want2) {
panic(fmt.Sprintf("got %s, want %s", got2, want2))
}
// stringify on an instantiated type, whose bound method is associated with
// the generic type StringStruct[T], which maps to a struct containing T.
x3 := []StringStruct[myint]{StringStruct[myint]{f: 11}, StringStruct[myint]{f: 10}, StringStruct[myint]{f: 9}}
got3 := stringify(x3)
want3 := []string{ "11", "10", "9" }
if !reflect.DeepEqual(got3, want3) {
panic(fmt.Sprintf("got %s, want %s", got3, want3))
}
[dev.typeparams] Add optional sub-dict entry for typeparam bound calls In the case that a generic function/method f does a method call on a type param allowed by its bound, an instantiation of f may do a direct method call of a concrete type or a method call defined on a generic type, depending on whether the passed type in a concrete type or an instantiated type with the appropriate method defined. See the test case boundmethod.go added to this change. In order to keep the dictionary format the same for all instantiations of a generic function/method, I decided to have an optional sub-dictionary entry for "bounds" calls. At the point that we are creating the actual dictionary, we can then fill in the needed sub-dictionary, if the type arg is an instantiated type, or a zeroed dictionary entry, if type arg is not instantiated and the method will be on a concrete type. In order to implement this, I now fill in n.Selection for "bounds" method calls in generic functions as well. Also, I need to calculate n.Selection correctly during import for the case where it is now set - method calls on generic types, and bounds calls on typeparams. With this change, the dictionaries/sub-dictionaries are correct for absdiff.go. The new test boundmethod.go illustrates the case where the bound sub-dict entry is not used for a dictionary for stringify[myint], but is used for a dictionary for stringify[StringInt[myint]]. Change-Id: Ie2bcb971b7019a9f1da68c97eb03da2333327457 Reviewed-on: https://go-review.googlesource.com/c/go/+/333456 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com>
2021-07-03 00:51:20 +00:00
}