The go/types package doesn't give us an easy way to get the type,
so just reject it.
Fixes#39743
Change-Id: I5404c10baede0fd2cf67980b06fbebd214a50dff
Reviewed-on: https://go-review.googlesource.com/c/go/+/239382
Reviewed-by: Ian Lance Taylor <iant@golang.org>
types.TypeString defaults to using the package path for references to names.
Provide our own types.Qualifier that uses just the package name,
since that is what the translated code has to use.
Fixes#39744
Change-Id: Icde289b2ed0fdd9b0a9aae6aae4557a8951d25a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/239381
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ignore struct tags when generating an instantiated names, and when
comparing types for identity.
Fixes#39737
Change-Id: I53e67fa1d09214dafc4088a59eb00e1a6f18ef3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/239379
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Move tracking of instantiations from translator to Importer,
so that we can track all instantiations within a package
to avoid duplicates.
Fixes#39749
Change-Id: If6cd5bcdc6e19c2d6481e62a6187ddf7f4fac72a
Reviewed-on: https://go-review.googlesource.com/c/go/+/239337
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously we instantiated the underlying type, so we didn't need this.
We stopped doing that to get the same type in the generated code,
but now we need to get the right type arguments, rather than just
leaving the type parameters there.
Fixes#39692
Change-Id: I56ba8ff017c37219e7cb9bb6e07a4beb8c50e9dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/238797
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It shows up when instantiating with types with a package path
containing a slash, as in net/url.Error.
Fixes#39642
Change-Id: Icf40e7bcdf1de7c84f58ebde35ebffadbb071d72
Reviewed-on: https://go-review.googlesource.com/c/go/+/238623
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Avoids crashing when we see a universe scope type in an instantiated type.
Change-Id: Iec3ebee291973180a63cd4cddef7e2f131a30053
Reviewed-on: https://go-review.googlesource.com/c/go/+/238622
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Turn an embedded type parameter into a regular field with the type
parameter as the name and the type argument as the type.
Fixes#39671
Change-Id: I0050499b90feb5085cac4452d53fa0dc6f614c48
Reviewed-on: https://go-review.googlesource.com/c/go/+/238621
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>
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>
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>
Specifically, this change accepts now:
1) Type parameters in type and function declarations, such as:
type B(type T) interface {
m(T) T
}
func f(type T B) (list []T) T
2) Type instantiations:
type T B(int)
3) Embedded instantiated types, with necessary extra parentheses:
type T struct {
(B(int)) // ()'s to distinguish from field B of type (int)
}
type T interface {
(B(int)) // ()'s to distinguish from method B with int argument
}
The compiler simply ignores the new constructs.
Change-Id: Iecb8354d3846d7a5786cbe7d92870d8a2d578133
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/736539
Reviewed-by: Robert Griesemer <gri@google.com>
If a type or type parameter does not satisfy a contract because the
type or type constraint is not found in the list of type constraints,
change
T does not satisfy C(T) (T type constraint int not found in interface{type ...})
to
T does not satisfy C(T) (T type constraint int not found in [type ...])
Also, before this change, if the contract had any required methods,
those were also listed; now we just list the type constraints.
If a defined type does not satisfy a contract because the underlying
type is not found in the list of type constraints, change
MyUint does not satisfy C(T) (MyUint not found in interface{type ...})
to
MyUint does not satisfy C(T) (uint not found in [type ...])
That is, when describing the type that is not found, use the underlying type,
not the defined type.
Change-Id: I345836c44921e2e13e7f02041839b5eb4df75c45
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/718718
Reviewed-by: Robert Griesemer <gri@google.com>
If a type parameter that has no type constraints is trying to satisfy
a contract that does have type constraints, change
T does not satisfy C(T) (missing type int)
to
T does not satisfy C(T) (T has no type constraints)
If a type parameter that has type constraints is trying to satisfy a
contract that has type constraints, but the parameter has type
constraints that the contract does not permit, change
T does not satisfy C(T) (missing type int)
to
T does not satisfy C(T) (T type constraint int not found in interface{type ...}
Change-Id: I3bd4f59b0544b382399d9b9d891a509ce62f56c3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/718426
Reviewed-by: Robert Griesemer <gri@google.com>
Otherwise we don't know the type of an instantiated type in an
instantiated function.
Change-Id: If7eb75dd920a3c9fc1b6992addcd3b91b6d425a9
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go2-dev/+/715718
Reviewed-by: Ian Lance Taylor <iant@google.com>
We can now translate code that use type inference when calling generic
functions. A couple of test cases were adjusted to use it.
Change-Id: I53c2f3dd8f9fcdb44b4a8f592acee1a19ff46f22
Added an accessor function to go/types:
// TParams returns the type parameters of the named type t, or nil.
func (t *Named) TParams() []*TypeName { return t.tparams }
Change-Id: Ife2322c73dd6eaecaed42655a57a37541661d1ed
The scheduler assumes two special invariants that apply to tuple
selectors (Select0 and Select1 ops):
1. There is only one tuple selector of each type per generator.
2. Tuple selectors and generators reside in the same block.
Prior to this CL the assumption was that these invariants would
only be broken by the CSE pass. The CSE pass therefore contained
code to move and de-duplicate selectors to fix these invariants.
However it is also possible to write relatively basic optimization
rules that cause these invariants to be broken. For example:
(A (Select0 (B))) -> (Select1 (B))
This rule could result in the newly added selector (Select1) being
in a different block to the tuple generator (see issue #38356). It
could also result in duplicate selectors if this rule matches
multiple times for the same tuple generator (see issue #39472).
The CSE pass will 'fix' these invariants. However it will only do
so when optimizations are enabled (since disabling optimizations
disables the CSE pass).
This CL moves the CSE tuple selector fixup code into its own pass
and makes it mandatory even when optimizations are disabled. This
allows tuple selectors to be treated like normal ops for most of
the compilation pipeline until after the new pass has run, at which
point we need to be careful to maintain the invariant again.
Fixes#39472.
Change-Id: Ia3f79e09d9c65ac95f897ce37e967ee1258a080b
Reviewed-on: https://go-review.googlesource.com/c/go/+/237118
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is a followup to CL 96495.
It should be simpler and more robust to achieve .bat files having
CRLF line endings by treating it as a binary file, like all other
files, and checking it in with the desired CRLF line endings.
A test is used to check the entire Go tree, short of directories
starting with "." and named "testdata", for any .bat files that
have anything other than strict CRLF line endings. This will help
catch any accidental modifications to existing .bat files or check
ins of new .bat files.
Importantly, this is compatible with how Gerrit serves .tar.gz files,
making it so that CRLF line endings are preserved.
The Go project is supported on many different environments, some of
which may have limited git implementations available, or none at all.
Relying on fewer git features and special rules makes it easier to
have confidence in the exact content of all files. Additionally, Go
development started in Subversion, moved to Perforce, then Mercurial,
and now uses Git.¹ Reducing its reliance on git-specific features will
help if there will be another transition in the project's future.
There are only 5 .bat files in the entire Go source tree, so a new one
being added is a rare event, and we prefer to do things in Go instead.
We still have the option of improving the experience for developers by
adding a pre-commit converter for .bat files to the git-codereview tool.
¹ https://groups.google.com/d/msg/golang-dev/sckirqOWepg/YmyT7dWJiocJFixes#39391.
For #37791.
Change-Id: I6e202216322872f0307ac96f1b8d3f57cb901e6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/236437
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Ian Lance Taylor
Robert Griesemer
Michael Munday
Xiangdong Ji
Dmitri Shuralyov