| Age | Commit message (Collapse) | Author |
|---|
|
We don't usually reformat the test directory, but all of the files in
test/typeparam are syntactically valid. I suspect the misformattings
here are because developers aren't re-installing gofmt with
-tags=typeparams, not intentionally exercising non-standard
formatting.
Change-Id: I3767d480434c19225568f3c7d656dc8589197183
Reviewed-on: https://go-review.googlesource.com/c/go/+/338093
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
union/tilde syntax
Did a mix of tilde and non-tilde usage. Tilde notation is not quite
fully functional, so no tests are currently trying to distinguish
(fail/not fail) based on tilde usage.
Change-Id: Ib50cec2fc0684f9d9f3561c889fd44c7a7af458c
Reviewed-on: https://go-review.googlesource.com/c/go/+/324572
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>
|
|
types2 will give us a constant with a type T, if an untyped constant is
used with another operand of type T (in a provably correct way). When we
substitute in the type args during stenciling, we now know the real type
of the constant. We may then need to change the BasicLit.val to be the
correct type (e.g. convert an int64Val constant to a floatVal constant).
Otherwise, later parts of the compiler will be confused.
Updated tests list.go and double.go with uses of untyped constants.
Change-Id: I9966bbb0dea3a7de1c5a6420f8ad8af9ca84a33e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303089
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>
|
|
method calls)
A type may now have a type param in it, either because it has been
composed from a function type param, or it has been declared as or
derived from a reference to a generic type. No objects or types with
type params can be exported yet. No generic type has a runtime
descriptor (but will likely eventually be associated with a dictionary).
types.Type now has an RParam field, which for a Named type can specify
the type params (in order) that must be supplied to fully instantiate
the type. Also, there is a new flag HasTParam to indicate if there is
a type param (TTYPEPARAM) anywhere in the type.
An instantiated generic type (whether fully instantiated or
re-instantiated to new type params) is a defined type, even though there
was no explicit declaration. This allows us to handle recursive
instantiated types (and improves printing of types).
To avoid the need to transform later in the compiler, an instantiation
of a method of a generic type is immediately represented as a function
with the method as the first argument.
Added 5 tests on generic types to test/typeparams, including list.go,
which tests recursive generic types.
Change-Id: Ib7ff27abd369a06d1c8ea84edc6ca1fd74bbb7c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/292652
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
