Adds a little note about `GO2PATH` and that it is required for the `go2go` tool.
Updates #39617
Change-Id: I9e3cea16a7d7539555180dc065957d6a56f390b9
GitHub-Last-Rev: 2aa6815df7
GitHub-Pull-Request: golang/go#39657
Reviewed-on: https://go-review.googlesource.com/c/go/+/238498
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add an accessor to go/types: HasTypeList for an interface type.
Fixes#39626
Change-Id: I880eabbe6660739cd7febc1df89eaa7f9262c8c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/238360
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Check for comparable embedded via a different embedded interface.
Check for comparable embedded in a defined interface type.
Change-Id: I8c9c576ad31443dcb77b4be71e29ab2284339cb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/238357
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It was already not possible to implement an interface that was or
embedded the predeclared interface "comparable" in ordinary (non-
constraint) use, but trying to do so would lead to confusing errors
(missing method "==").
Simply disallow the use of such interfaces outside constraints,
as we do for interfaces containing type lists.
Change-Id: I15ccf1b77226a50baf16df46192e90144208f9dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/238300
Reviewed-by: Robert Griesemer <gri@golang.org>
It turns out that defaultImporter has modifiable fields, so making it a
package scope variable can cause confusion in the use by test/run.go.
Change-Id: I33b060f2ffd17639312e7aa15a632268a3c14ab1
Reviewed-on: https://go-review.googlesource.com/c/go/+/238299
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since we have to recompute the underlying type of each type in a
type list after instantiation (if any), there is no need to restrict
the types in the type list anymore.
Per the adjustment in the design draft.
Change-Id: I51ced90788e06ed4a9dbd34566e3baca7f3afe20
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/771574
Reviewed-by: Robert Griesemer <gri@google.com>
The underlying type of each type list entry must be computed
(again) _after_ the interface was instantiated because its
original typelist may have contained type parameters that were
substituted with defined types.
Passes all.bash.
Change-Id: I65a234fe6b9bc7b36121532410a0ecc29061516e
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/770445
Reviewed-by: Robert Griesemer <gri@google.com>
- fix endless recursion when caused by trace output for self-referential generic types
- print pointer designation of type parameters in type parameter lists
Change-Id: I02d985187ee5e42fdaece2e7420824de8c90a906
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/770152
Reviewed-by: Robert Griesemer <gri@google.com>
If a defined type is passed as an argument for a paramater
of a composite generic but unnamed type (and vice versa),
use the defined type's underlying type for type inference
rather than fail.
Passes all.bash.
Change-Id: I90b33b549c1d0e7569c1520b0f8e45a67152df43
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/770149
Reviewed-by: Robert Griesemer <gri@google.com>
types.Identical will report that two instantiated types are different
even if they are instantiated with the same type arguments.
Change our comparison so that we treat them as the same.
This lets us drop fully resolving all types, which is good because
that wasn't correct anyhow.
Change-Id: Ibcf2dc08896ecacb11ca302627e5d0c6f0722da7
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/769080
Reviewed-by: Ian Lance Taylor <iant@google.com>
There are still a couple of issues with pointer type parameters
that have constraints containing type lists, but at least as far
as method constraints are concerned the code is now matching the
design.
Passes all.bash.
Change-Id: I7b7ad9e03bc6ed159dca2343d3fa6a04fc188659
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/765805
Reviewed-by: Robert Griesemer <gri@google.com>
Implement intersection of (sum) type lists so we can correctly
compute a type bound's type list if a type bound embeds other
type bounds (interfaces).
For type bounds A, B we want to preserve the property
"A embeds B" implies "A satisfies B"
Because type bounds are interfaces this is already true when
considering method sets only. But type bounds also may contain
type lists, and for this property to be true, type lists must
be intersected.
The intersection of two non-empty type lists with different types
may be the empty list (nil), which means that no type satisfies
the type bound. Because we already use nil to indicate the absence
of a type list (i.e., ignoring methods, any type satisfies the type
bound) we need a separate representation. This CL introduces two
new internal types, bottom and top, which stand for "no type" and
"any type" (they represent the bottom and top of the type lattice).
Since nil is already used for what should be the top type, and we
rely on the fact that the zero value for an Interface type is a
valid empty interface, we keep using nil in type lists to indicate
the top type. Eventually we may want to clean this up.
This CL also refines the understanding of type parameters: The
underlying type of a type parameter must be itself (it cannot be
defined by the associated type bound as assumed in a prior CL).
Consider the declaration
type T(type P) P
which declares a new defined, generic type. The question is, what
is the underlying type of T, i.e., the type which T represents
with a (new) name? (This type is stored in the underlying field
of a Named type.) The only possible answer is P, because otherwise
instantiation of T with any other type Q wouldn't produce that type
Q.
Thus, when checking if an operation is applicable on a value of type
parameter type, we need to explicitly get the type parameter's
"operational type" which is defined by the type parameter's type
bound; specifically the type bounds's type list (which is represented
as a sum type).
Passes all.bash.
Change-Id: Iad7e99884fd8f40a70f75c6470f1817d74994f48
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/764158
Reviewed-by: Robert Griesemer <gri@google.com>
The type-checker type-checks method type parameters like
function type parameters without any extra work. But the
current design draft does not permit them and the go2go
translator does not expect them.
Add a flag to enable them for type checker tests, but do
not accept them by default. Instead, type-check but report
an error.
Passes all.bash.
Change-Id: Iec02f4a951a3faccd2409d97d48bc4dd4536a750
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/764012
Reviewed-by: Robert Griesemer <gri@google.com>
This matches the latest design draft. It's unclear what the
correct approach is here, and there is an easy work-around:
just assign to an interface variable first.
Passes all.bash.
Change-Id: Ic1d6ed3de6333505e2044a318ea05fb984b408cf
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/764001
Reviewed-by: Robert Griesemer <gri@google.com>
These are from the latest version of the design draft.
There are still a couple of FromStrings test cases that don't yet work.
Change-Id: I057875820d8250012c06faeabda4637f0585b6f8
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/763941
Reviewed-by: Ian Lance Taylor <iant@google.com>
If a type parameter's type bound contains a type list, we can view that as
the underlying type(s) of the type parameter. If there is no type list the
underlying type of a type parameter is itself.
This approach resolves several open issues and clarifies the relationship
between type bound type lists and the type parameters. It also provides a
sensible definition for the underlying type of a type parameter (it will
take some more experimentation to see if this view is holding up within
the axiomatic framework of generic Go).
To implement this new view, in this CL we introduce the (implementation-
internal) notion of a sum type. A sum type is a set of two or more
distinct types. With this, we can view an interface with a type list as
an interface that provides a _single_ underlying type, which may be a
sum type.
Defining the underlying type of a type parameter this way enables a lot
of so far failing tests to work. In other instances, we have to implement
type-checking for sum types and can ignore the connection with generic code.
This simplifies the implementation and leads to a better separation of
concerns.
As part of this change:
- Several test cases in testdata/todos.go2 now work as expected
and move to testdata/issues.go2.
- Fix, clarify, and add various comments.
Passes all.bash.
Change-Id: I25a435b2ccd0c9f9fda5369bc998e52fe120ee0b
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/762619
Reviewed-by: Robert Griesemer <gri@google.com>
The implementation of conversions T(x) between integers and floating-point
numbers checks that both T and x have either integer or floating-point
type. When the type of T or x is a type parameter, the respective simple
predicate disjunction in the implementation was wrong because if a type list
contains both an integer and a floating-point type, the type parameter is
neither an integer or a floating-point number.
Change-Id: I007aa956007ab1a0228e0ee2fca05804686b404c
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/759562
Reviewed-by: Robert Griesemer <gri@google.com>
The existing code collected empty fields. Collect the actual
field and added type string test.
(This was not found before because the generic tests are still
disabled in this port because of different position information.)
Change-Id: I959711892aac3c8f7587a4025c4b32f1598f5df3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/756088
Reviewed-by: Robert Griesemer <gri@google.com>
Ahmed W
Ian Lance Taylor
Robert Griesemer