This is a rewrite to drop the type keyword for parameterized functions
and types, and to instead always provide a constraint.
We can revert if we don't like this approach.
Change-Id: If4669fb4e2015067e9f955ff8567ed421be639ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/248880
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a rule change in an attempt to streamline interface satisfaction:
If a (constraint) interface contains a type list, a type argument's type
or underlying type must be included in the type list (and the interface's
methods must be present, of course). Until now, a type argument's under-
lying type had to be one of the underlying types of the types in the type
list.
The effect is subtle: Because an underlying type is never a defined type,
if a type list contains defined types, only those defined types satisfy
the interface. If we want the interface to be more flexible, we can in-
clude non-defined types in its type list. In the common case, type lists
simply contain predeclared types (whose underlying types are themselves),
so this doesn't matter. An observable difference appears only for code
that currently uses defined types in constraint type lists: such code
becomes slightly more restrictive.
The primary benefit of this change is that it opens the door for general
(non-constraint) use of interfaces with type lists: Using the same rules
as for constraint satisfaction, a value may be assigned to a variable of
such an interface if it or its underlying type of the value is included
int the interface's type list. If the type list contains only defined types,
the respective interface acts like a sum type: it can only contain values
of those types (and nil).
This CL only changes the rules for constraints. It does not permit
interfaces with type lists for general (non-constraint) use for now.
Change-Id: I3f25b9d883dd865a74c583efee4be2e22258d493
Reviewed-on: https://go-review.googlesource.com/c/go/+/248265
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This change makes it possible to declare a generic type with exactly
one type parameter and no constraints without any special syntactic
augmentation: Instead, the parser determines whether a declaration
of the form
type T[P] type_literal
is an array or generic declaration based on how the type parameter
P is used in type_literal. If P appears only in array lengths (if
at all) in type_literal, T is an array type. Otherwise it is a
generic type.
Change-Id: I6c1d62d61d04f322d73ee16840e0f3ffe299f4c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/248438
Reviewed-by: Robert Griesemer <gri@golang.org>
For fine-tuning the type parameter list notation. If we
proceed with square brackets rather than parentheses, we
don't need the "type" keyword in type parameter lists in
many cases. However, generic type declarations with one
type parameter and no constraint must somehow disambiguate
from array type declarations:
type T[P] E
could be a generic type, or an array type declaration
type T [P]E
There's a variety of choices for disambiguation, such as:
type T[type P] E // what we do now
type T[P interface{}] E // currently permitted
type T[P any] E // permitted with this CL
type T[P,] E // currently permitted
If we abandon the "type" keyword (currently optional), we
need an alternative. Writing the constraint seems nicer than
the comma option (in Go, all parameter lists permit a trailing
comma, but an array length specification doesn't allow it).
If we write the constraint, which is often the empty interface,
being able to write "any" would be more convenient.
In the past we have refused to add "any" to the language. There
may be many more situations where we need to specify an empty
constraint (any) so perhaps adding "any" is now justified. It
would also streamline a lot of existing code such as
Printf(format string, args... any)
Change-Id: I366342ba8d981d344c96b1ceb60f61d963e9175a
Reviewed-on: https://go-review.googlesource.com/c/go/+/248263
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Updated existing tests to more closely match the go/types
tests; added *B.go2 versions for some tests, using [] for
type parameters.
Change-Id: Ie7cfd9f5515f541d9422a2b2ab8a5d3e02d0499a
Reviewed-on: https://go-review.googlesource.com/c/go/+/246261
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The existing code didn't accept an instantiated imported (qualified) type
as type for a regular function parameter.
Also: Simplified logic around use of typeContext flag when []'s
are used for type parameters.
Change-Id: Ic6c60e943344a976f5b8546c8a378ebd32a82d90
Reviewed-on: https://go-review.googlesource.com/c/go/+/246260
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Still missing:
- embedded []-instantiated types in interfaces
- *B.go2 tests which exist for go/types
Change-Id: I3dd115fcd67f725144062c90550a91fcded1cbe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/246259
Reviewed-by: Robert Griesemer <gri@golang.org>
The remaining uses of token.Token are needed for the go/constant API.
Change-Id: I5dc8be1fae16217433da1acb5606fd1d7b8eea54
Reviewed-on: https://go-review.googlesource.com/c/go/+/246257
Reviewed-by: Robert Griesemer <gri@golang.org>
This brings types2 (the syntax-based type-checker) up-to-date
with the latest version of the prototype go/types version. It
does not yet include the *B.go2 tests (using square brackets)
or the relevant syntax parser changes.
Tests that check error positions continue to be disabled since
the synax parser records slightly different positions than the
go/parser (to be fixed).
Manually verified that selected *.go2 tests which don't report
errors pass. Type-checks the std library without errors.
Change-Id: If859b180bba8362db86c211eeb4dc2d46255df36
Reviewed-on: https://go-review.googlesource.com/c/go/+/246137
Reviewed-by: Robert Griesemer <gri@golang.org>
This test passes type-checking without problems but the
generated code causes a cmd/compile error (filed #40486).
Updates #39634.
Change-Id: If3dd28605f6d8792c6bd5bb032624e9a6140b2c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/245742
Reviewed-by: Robert Griesemer <gri@golang.org>
When checking if a type is parameterized, we only care about
type parameters bound to the specific type, not "free" type
parameters. The old code simply looked for "any" type parameter.
Change-Id: I6a3fe5ac7e3150c5796d4b7576682ab3d4b8558f
Reviewed-on: https://go-review.googlesource.com/c/go/+/245741
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
- Reorganize testdata directory to either contain single-file packages
or (one level of) sub-directories containing multi-file packages.
- Add TestTestdata that runs all the tests in testdata.
- Change TestCheck to only test files explicitly provided via -files.
Providing -v when running these tests now enumerates the packages.
For TestCheck it also prints the type-checking trace.
Change-Id: I66536881789234af030a0a2c9fc096822f593782
Reviewed-on: https://go-review.googlesource.com/c/go/+/244629
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Just traverse the respective directories.
Change-Id: I21432e23550d8331e61d3392e8488c81183ab6f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/244628
Reviewed-by: Robert Griesemer <gri@golang.org>
Experiment: Make "type" keyword optional in generic type declarations when
it is clear that we can't have an array type declaration. This is the case
when we have one the following:
- more than one type parameter
- a type parameter with a constraint
- a trailing comma in the type parameter list
Change-Id: If6c473ba93b993a7c15ff2f7e7302709cc985f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/244623
Reviewed-by: Robert Griesemer <gri@golang.org>
Report an error instead for now until we have a better idea.
(It's unclear what these operations should do as they are
defined to return a compile-time constant which we can't
know in general.)
Fixes#40301.
Change-Id: I22a991311de117bc00d52b67b4ce862ea09d855a
Reviewed-on: https://go-review.googlesource.com/c/go/+/244622
Reviewed-by: Robert Griesemer <gri@golang.org>
We keep an import spec if it uses a local alias. Avoid importing it
again, unless it is required by something else.
Fixes#40318
Change-Id: If90de3bf30412645c9144083372e6b07df3c6a0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/244621
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Instead, add the field "Brackets" to ast.CallExpr to identify
the bracket used for the (type) parameters. Adjust dependencies.
Change-Id: I6a73b0517ac518d8055e7fadbfb8662dfff585c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/244618
Reviewed-by: Ian Lance Taylor <iant@golang.org>
1) Implement full bidirectional unification for general use.
2) Implement constraint type inference using bidirectional unification.
3) Add flag Config.InferFromConstraints to enable constraint type
inference (disabled by default).
If we don't have all type arguments (provided or inferred) for a
function call, constraint type inference attempts to infer them
from type parameter constraints that are "structural", i.e., whose
interfaces contain exactly one (non-interface) type in their type
lists. For instance, given
[type P interface{}, Q interface{type []P}]
the constraint for Q requires that the (underlying) structure of
the type argument for Q must match the underlying type of the type
argument provided for P. If only a type argument for P is given, say
say int, we can infer a type argument for Q, which would be []int.
Change-Id: I8508412ad96a0969d2033e99510c56db0f78177e
Reviewed-on: https://go-review.googlesource.com/c/go/+/244061
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is necessary for continued support for the prototype in gopls.
Fixesgolang/go#40316
Change-Id: Iafab2e78cfdfd7415d2e2419b8ed1abe6e6216c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/243717
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
We can roll back this CL if we go back to parentheses.
Change-Id: Ide85330f4c362dad6ae964c6cc1fd0fc6c8a6a60
Reviewed-on: https://go-review.googlesource.com/c/go/+/243162
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We can roll back this CL if we go back to parentheses.
Change-Id: Ideb7dbe8e3c4499d76518a5c9b6f7931a7c103a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/243158
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Not setting the UseBracket mode still permits the parser to switch
to using brackets depending on the first generic type or function
declaration.
Change-Id: I2ee1235cfe58108ce1f5fd4a7fa1ce81f9e0ec0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/242904
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The first generic type or function declaration encountered in a file chosing
square brackets switches the parser to use square brackets for the remainder of
the file.
Removed the need for extra type declarations in tests solely to switch to [].
Change-Id: Ia8d0c16e69b7e9b0e5397fed7405c5c4afc66451
Reviewed-on: https://go-review.googlesource.com/c/go/+/242899
Reviewed-by: Robert Griesemer <gri@golang.org>
Also: Don't strip parentheses around unnamed generic parameter
types when () are used for type instantiations (was bug).
Change-Id: I74edde2be2a01d740d2275e5d8768a5c25fa3302
Reviewed-on: https://go-review.googlesource.com/c/go/+/242717
Reviewed-by: Robert Griesemer <gri@golang.org>
- The first type declaration using [] for type parameters
switches the parser to using [] for type parameters and
type instantiations. Otherwise it uses ().
- Type parameters are now always accepted with any function
or method declaration. It is up to the consumer of the AST
to reject them as necessary.
- Type parameters are now never accepted in the receiver
or result parameter list.
- testdata/xxxB.go2 tests correspond to the testdata/xxx.go2
tests but use [] instead of ().
- See also https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8
Change-Id: I21b14f9463f7f49deba83b64450a0723b4b1d171
Reviewed-on: https://go-review.googlesource.com/c/go/+/242520
Reviewed-by: Ian Lance Taylor <iant@golang.org>
No test case because there is still no test harness for a complex
package heirarchy.
Fixes#40063
Change-Id: Iebe627dd7b2a3e967d437bee61c9d15c7a159fc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/241217
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This can happen due to earlier errors. This change avoids the panic
but reports a follow-up error. Not ideal, but good enough for now.
Fixes#40056.
Change-Id: I500d4fc2b058cdc70f28883ff8d004df4b43fe4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/241130
Reviewed-by: Robert Griesemer <gri@golang.org>
Ian Lance Taylor
Robert Griesemer
tdakkota
Rebecca Stambler