go/test/typeparam/settable.go

124 lines
2.7 KiB
Go
Raw Normal View History

// run
// 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.
package main
import (
"fmt"
"strconv"
)
// Various implementations of fromStrings().
[dev.typeparams] cmd/compile: get export/import of generic types & functions working The general idea is that we now export/import typeparams, typeparam lists for generic types and functions, and instantiated types (instantiations of generic types with either new typeparams or concrete types). This changes the export format -- the next CL in the stack adds the export versions and checks for it in the appropriate places. We always export/import generic function bodies, using the same code that we use for exporting/importing the bodies of inlineable functions. To avoid complicated scoping, we consider all type params as unique and give them unique names for types1. We therefore include the types2 ids (subscripts) in the export format and re-create on import. We always access the same unique types1 typeParam type for the same typeparam name. We create fully-instantiated generic types and functions in the original source package. We do an extra NeedRuntimeType() call to make sure that the correct DWARF information is written out. We call SetDupOK(true) for the functions/methods to have the linker automatically drop duplicate instantiations. Other miscellaneous details: - Export/import of typeparam bounds works for methods (but not typelists) for now, but will change with the typeset changes. - Added a new types.Instantiate function roughly analogous to the types2.Instantiate function recently added. - Always access methods info from the original/base generic type, since the methods of an instantiated type are not filled in (in types2 or types1). - New field OrigSym in types.Type to keep track of base generic type that instantiated type was based on. We use the generic type's symbol (OrigSym) as the link, rather than a Type pointer, since we haven't always created the base type yet when we want to set the link (during types2 to types1 conversion). - Added types2.AsTypeParam(), (*types2.TypeParam).SetId() - New test minimp.dir, which tests use of generic function Min across packages. Another test stringimp.dir, which also exports a generic function Stringify across packages, where the type param has a bound (Stringer) as well. New test pairimp.dir, which tests use of generic type Pair (with no methods) across packages. - New test valimp.dir, which tests use of generic type (with methods and related functions) across packages. - Modified several other tests (adder.go, settable.go, smallest.go, stringable.go, struct.go, sum.go) to export their generic functions/types to show that generic functions/types can be exported successfully (but this doesn't test import). Change-Id: Ie61ce9d54a46d368ddc7a76c41399378963bb57f Reviewed-on: https://go-review.googlesource.com/c/go/+/319930 Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-13 22:37:36 +00:00
type Setter[B any] interface {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
Set(string)
go/types, types2: correctly consider ~ (tilde) in constraint type inference When doing constraint type inference, we must consider whether the constraint's core type is precise (no tilde) or imprecise (tilde, or not a single specific type). In the latter case, we cannot infer an unknown type argument from the (imprecise) core type because there are infinitely many possible types. For instance, given [E ~byte] if we don't know E, we cannot infer that E must be byte (it could be myByte, etc.). On the other hand, if we do know the type argument, say for S in this example: [S ~[]E, E any] we must consider the underlying type of S when matching against ~[]E because we have a tilde. Because constraint type inference may infer type arguments that were not eligible initially (because they were unknown and the core type is imprecise), we must iterate the process until nothing changes any- more. For instance, given [S ~[]E, M ~map[string]S, E any] where we initially only know the type argument for M, we must ignore S (and E) at first. After one iteration of constraint type inference, S is known at which point we can infer E as well. The change is large-ish but the actual functional changes are small: - There's a new method "unknowns" to determine the number of as of yet unknown type arguments. - The adjCoreType function has been adjusted to also return tilde and single-type information. This is now conveniently returned as (*term, bool), and the function has been renamed to coreTerm. - The original constraint type inference loop has been adjusted to consider tilde information. - This adjusted original constraint type inference loop has been nested in another loop for iteration, together with some minimal logic to control termination. The remaining changes are modifications to tests: - There's a substantial new test for this issue. - Several existing test cases were adjusted to accomodate the fact that they inferred incorrect types: tildes have been removed throughout. Most of these tests are for pathological cases. - A couple of tests were adjusted where there was a difference between the go/types and types2 version. Fixes #51229. Change-Id: If0bf5fb70ec22913b5a2da89adbf8a27fbc921d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/387977 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-02-25 06:11:40 +00:00
*B
}
// Takes two type parameters where PT = *T
[dev.typeparams] cmd/compile: get export/import of generic types & functions working The general idea is that we now export/import typeparams, typeparam lists for generic types and functions, and instantiated types (instantiations of generic types with either new typeparams or concrete types). This changes the export format -- the next CL in the stack adds the export versions and checks for it in the appropriate places. We always export/import generic function bodies, using the same code that we use for exporting/importing the bodies of inlineable functions. To avoid complicated scoping, we consider all type params as unique and give them unique names for types1. We therefore include the types2 ids (subscripts) in the export format and re-create on import. We always access the same unique types1 typeParam type for the same typeparam name. We create fully-instantiated generic types and functions in the original source package. We do an extra NeedRuntimeType() call to make sure that the correct DWARF information is written out. We call SetDupOK(true) for the functions/methods to have the linker automatically drop duplicate instantiations. Other miscellaneous details: - Export/import of typeparam bounds works for methods (but not typelists) for now, but will change with the typeset changes. - Added a new types.Instantiate function roughly analogous to the types2.Instantiate function recently added. - Always access methods info from the original/base generic type, since the methods of an instantiated type are not filled in (in types2 or types1). - New field OrigSym in types.Type to keep track of base generic type that instantiated type was based on. We use the generic type's symbol (OrigSym) as the link, rather than a Type pointer, since we haven't always created the base type yet when we want to set the link (during types2 to types1 conversion). - Added types2.AsTypeParam(), (*types2.TypeParam).SetId() - New test minimp.dir, which tests use of generic function Min across packages. Another test stringimp.dir, which also exports a generic function Stringify across packages, where the type param has a bound (Stringer) as well. New test pairimp.dir, which tests use of generic type Pair (with no methods) across packages. - New test valimp.dir, which tests use of generic type (with methods and related functions) across packages. - Modified several other tests (adder.go, settable.go, smallest.go, stringable.go, struct.go, sum.go) to export their generic functions/types to show that generic functions/types can be exported successfully (but this doesn't test import). Change-Id: Ie61ce9d54a46d368ddc7a76c41399378963bb57f Reviewed-on: https://go-review.googlesource.com/c/go/+/319930 Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-13 22:37:36 +00:00
func fromStrings1[T any, PT Setter[T]](s []string) []T {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
result := make([]T, len(s))
for i, v := range s {
// The type of &result[i] is *T which is in the type list
// of Setter, so we can convert it to PT.
p := PT(&result[i])
// PT has a Set method.
p.Set(v)
}
return result
}
[dev.typeparams] cmd/compile: get export/import of generic types & functions working The general idea is that we now export/import typeparams, typeparam lists for generic types and functions, and instantiated types (instantiations of generic types with either new typeparams or concrete types). This changes the export format -- the next CL in the stack adds the export versions and checks for it in the appropriate places. We always export/import generic function bodies, using the same code that we use for exporting/importing the bodies of inlineable functions. To avoid complicated scoping, we consider all type params as unique and give them unique names for types1. We therefore include the types2 ids (subscripts) in the export format and re-create on import. We always access the same unique types1 typeParam type for the same typeparam name. We create fully-instantiated generic types and functions in the original source package. We do an extra NeedRuntimeType() call to make sure that the correct DWARF information is written out. We call SetDupOK(true) for the functions/methods to have the linker automatically drop duplicate instantiations. Other miscellaneous details: - Export/import of typeparam bounds works for methods (but not typelists) for now, but will change with the typeset changes. - Added a new types.Instantiate function roughly analogous to the types2.Instantiate function recently added. - Always access methods info from the original/base generic type, since the methods of an instantiated type are not filled in (in types2 or types1). - New field OrigSym in types.Type to keep track of base generic type that instantiated type was based on. We use the generic type's symbol (OrigSym) as the link, rather than a Type pointer, since we haven't always created the base type yet when we want to set the link (during types2 to types1 conversion). - Added types2.AsTypeParam(), (*types2.TypeParam).SetId() - New test minimp.dir, which tests use of generic function Min across packages. Another test stringimp.dir, which also exports a generic function Stringify across packages, where the type param has a bound (Stringer) as well. New test pairimp.dir, which tests use of generic type Pair (with no methods) across packages. - New test valimp.dir, which tests use of generic type (with methods and related functions) across packages. - Modified several other tests (adder.go, settable.go, smallest.go, stringable.go, struct.go, sum.go) to export their generic functions/types to show that generic functions/types can be exported successfully (but this doesn't test import). Change-Id: Ie61ce9d54a46d368ddc7a76c41399378963bb57f Reviewed-on: https://go-review.googlesource.com/c/go/+/319930 Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-13 22:37:36 +00:00
func fromStrings1a[T any, PT Setter[T]](s []string) []PT {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
result := make([]PT, len(s))
for i, v := range s {
// The type new(T) is *T which is in the type list
// of Setter, so we can convert it to PT.
result[i] = PT(new(T))
p := result[i]
// PT has a Set method.
p.Set(v)
}
return result
}
// Takes one type parameter and a set function
func fromStrings2[T any](s []string, set func(*T, string)) []T {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
results := make([]T, len(s))
for i, v := range s {
set(&results[i], v)
}
return results
}
[dev.typeparams] cmd/compile: get export/import of generic types & functions working The general idea is that we now export/import typeparams, typeparam lists for generic types and functions, and instantiated types (instantiations of generic types with either new typeparams or concrete types). This changes the export format -- the next CL in the stack adds the export versions and checks for it in the appropriate places. We always export/import generic function bodies, using the same code that we use for exporting/importing the bodies of inlineable functions. To avoid complicated scoping, we consider all type params as unique and give them unique names for types1. We therefore include the types2 ids (subscripts) in the export format and re-create on import. We always access the same unique types1 typeParam type for the same typeparam name. We create fully-instantiated generic types and functions in the original source package. We do an extra NeedRuntimeType() call to make sure that the correct DWARF information is written out. We call SetDupOK(true) for the functions/methods to have the linker automatically drop duplicate instantiations. Other miscellaneous details: - Export/import of typeparam bounds works for methods (but not typelists) for now, but will change with the typeset changes. - Added a new types.Instantiate function roughly analogous to the types2.Instantiate function recently added. - Always access methods info from the original/base generic type, since the methods of an instantiated type are not filled in (in types2 or types1). - New field OrigSym in types.Type to keep track of base generic type that instantiated type was based on. We use the generic type's symbol (OrigSym) as the link, rather than a Type pointer, since we haven't always created the base type yet when we want to set the link (during types2 to types1 conversion). - Added types2.AsTypeParam(), (*types2.TypeParam).SetId() - New test minimp.dir, which tests use of generic function Min across packages. Another test stringimp.dir, which also exports a generic function Stringify across packages, where the type param has a bound (Stringer) as well. New test pairimp.dir, which tests use of generic type Pair (with no methods) across packages. - New test valimp.dir, which tests use of generic type (with methods and related functions) across packages. - Modified several other tests (adder.go, settable.go, smallest.go, stringable.go, struct.go, sum.go) to export their generic functions/types to show that generic functions/types can be exported successfully (but this doesn't test import). Change-Id: Ie61ce9d54a46d368ddc7a76c41399378963bb57f Reviewed-on: https://go-review.googlesource.com/c/go/+/319930 Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-13 22:37:36 +00:00
type Setter2 interface {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
Set(string)
}
// Takes only one type parameter, but causes a panic (see below)
[dev.typeparams] cmd/compile: get export/import of generic types & functions working The general idea is that we now export/import typeparams, typeparam lists for generic types and functions, and instantiated types (instantiations of generic types with either new typeparams or concrete types). This changes the export format -- the next CL in the stack adds the export versions and checks for it in the appropriate places. We always export/import generic function bodies, using the same code that we use for exporting/importing the bodies of inlineable functions. To avoid complicated scoping, we consider all type params as unique and give them unique names for types1. We therefore include the types2 ids (subscripts) in the export format and re-create on import. We always access the same unique types1 typeParam type for the same typeparam name. We create fully-instantiated generic types and functions in the original source package. We do an extra NeedRuntimeType() call to make sure that the correct DWARF information is written out. We call SetDupOK(true) for the functions/methods to have the linker automatically drop duplicate instantiations. Other miscellaneous details: - Export/import of typeparam bounds works for methods (but not typelists) for now, but will change with the typeset changes. - Added a new types.Instantiate function roughly analogous to the types2.Instantiate function recently added. - Always access methods info from the original/base generic type, since the methods of an instantiated type are not filled in (in types2 or types1). - New field OrigSym in types.Type to keep track of base generic type that instantiated type was based on. We use the generic type's symbol (OrigSym) as the link, rather than a Type pointer, since we haven't always created the base type yet when we want to set the link (during types2 to types1 conversion). - Added types2.AsTypeParam(), (*types2.TypeParam).SetId() - New test minimp.dir, which tests use of generic function Min across packages. Another test stringimp.dir, which also exports a generic function Stringify across packages, where the type param has a bound (Stringer) as well. New test pairimp.dir, which tests use of generic type Pair (with no methods) across packages. - New test valimp.dir, which tests use of generic type (with methods and related functions) across packages. - Modified several other tests (adder.go, settable.go, smallest.go, stringable.go, struct.go, sum.go) to export their generic functions/types to show that generic functions/types can be exported successfully (but this doesn't test import). Change-Id: Ie61ce9d54a46d368ddc7a76c41399378963bb57f Reviewed-on: https://go-review.googlesource.com/c/go/+/319930 Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-13 22:37:36 +00:00
func fromStrings3[T Setter2](s []string) []T {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
results := make([]T, len(s))
for i, v := range s {
// Panics if T is a pointer type because receiver is T(nil).
results[i].Set(v)
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
}
return results
}
// Two concrete types with the appropriate Set method.
type SettableInt int
func (p *SettableInt) Set(s string) {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
i, err := strconv.Atoi(s)
if err != nil {
panic(err)
}
*p = SettableInt(i)
}
type SettableString struct {
s string
}
func (x *SettableString) Set(s string) {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
x.s = s
}
func main() {
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
s := fromStrings1[SettableInt, *SettableInt]([]string{"1"})
if len(s) != 1 || s[0] != 1 {
panic(fmt.Sprintf("got %v, want %v", s, []int{1}))
}
s2 := fromStrings1a[SettableInt, *SettableInt]([]string{"1"})
if len(s2) != 1 || *s2[0] != 1 {
x := 1
panic(fmt.Sprintf("got %v, want %v", s2, []*int{&x}))
}
// Test out constraint type inference, which should determine that the second
// type param is *SettableString.
ps := fromStrings1[SettableString]([]string{"x", "y"})
cmd/compile: getting more built-ins to work with generics For Builtin ops, we currently stay with using the old typechecker to transform the call to a more specific expression and possibly use more specific ops. However, for a bunch of the ops, we delay calling the old typechecker if any of the args have type params, for a variety of reasons. In the near future, we will start creating separate functions that do the same transformations as the old typechecker for calls, builtins, indexing, comparisons, etc. These functions can then be called at noder time for nodes with no type params, and at stenciling time for nodes with type params. Remove unnecessary calls to types1 typechecker for most kinds of statements (still need it for SendStmt, AssignStmt, ReturnStmt, and SelectStmt). In particular, we don't need it for RangeStmt, and this avoids some complaints by the types1 typechecker on generic code. Other small changes: - Fix check on whether to delay calling types1-typechecker on type conversions. Should check if HasTParam is true, rather than if the type is directly a TYPEPARAM. - Don't call types1-typechecker on an indexing operation if the left operand has a typeparam in its type and is not obviously a TMAP, TSLICE, or TARRAY. As above, we will eventually have to create a new function that can do the required transformations (for complicated cases) at noder time or stenciling time. - Copy n.BuiltinOp in subster.node() - The complex arithmetic example in absdiff.go now works. - Added new tests double.go and append.go - Added new example with a new() call in settable.go Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/301951 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dan Scales <danscales@google.com> Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-03-12 19:36:02 +00:00
if len(ps) != 2 || ps[0] != (SettableString{"x"}) || ps[1] != (SettableString{"y"}) {
panic(s)
}
s = fromStrings2([]string{"1"}, func(p *SettableInt, s string) { p.Set(s) })
if len(s) != 1 || s[0] != 1 {
panic(fmt.Sprintf("got %v, want %v", s, []int{1}))
}
defer func() {
if recover() == nil {
panic("did not panic as expected")
}
}()
// This should type check but should panic at run time,
// because it will make a slice of *SettableInt and then call
// Set on a nil value.
fromStrings3[*SettableInt]([]string{"1"})
}