When we used ()'s for type parameters, we needed to relax the rules for
embedded struct fields and interface methods: parenthesized embedded
fields and methods were necessary to disambiguate from other constructs.
Now that we use []'s, we can go back to the existing Go rules.
Minor cleanups.
Change-Id: I45399e5b5592c76654a5d504f8bb8b23fff53b85
Reviewed-on: https://go-review.googlesource.com/c/go/+/253997
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
- type and ordinary parameter list follow the same syntax
- type parameters are enclosed in [], ordinary parameters use ()
- type parameter lists cannot be empty
- all type parameters must be named
Adjusted parser to follow new syntax. Lots of related cleanups.
Adjusted testdata/go2/x.go2 tests and removed the xB.go2 tests.
Preliminary adjustments to types2 package to make tests pass.
Change-Id: Ic4e6597180b97f06345f60cafa9bfc7c642a26ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/253040
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 record the results of constraint type inference
when it was applied to a partial list of (provided) type parameters.
Changed Info.Inferred map to accept *ast.CallExpr and *ast.IndexExpr
as keys ("call" may be f(x) or f[T]).
Updates #41216.
Change-Id: I5da7467d01643bf74fb78f6c6728209cbd4006c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/253258
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Now that we have mostly settled on the type parameter list syntax we should
probably remove the various modes of parsing and printing. For now just set
the UseBrackets flag explicitly when printing.
Updates #41195.
Change-Id: I56b06b4f930908579a38a140e8221618c8e2fa17
Reviewed-on: https://go-review.googlesource.com/c/go/+/252879
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
If the cause is a method with incorrect signature, report the
expected and presented signature.
Updates #41125.
Change-Id: Ibd0fa23547b77df924ec5421cc8e657d41c5a5a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/251717
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Error doesn't just apply to ordinary function parameters anymore;
it could be a (type or function) type parameter list.
Change-Id: Ied75d363917079b265140eb1f1a291d98e019229
Reviewed-on: https://go-review.googlesource.com/c/go/+/251558
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Per the restriction in the current design draft.
Change-Id: Ic6ff597849335fa23de22529999d20aacfc205b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/251140
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Per the latest update to the design draft.
Change-Id: I026b52082e739f6806cd37a0f3e88a546a6f2e90
Reviewed-on: https://go-review.googlesource.com/c/go/+/251139
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When using unified parameter list syntax, an empty type parameter
list in a type declaration is impossible (it means a slice type).
For symmetry, and because it doesn't make sense to support it,
disallow empty type parameter lists in function declarations.
Accept (parse) them but report a syntax error.
Analogously, disallow empty index/slice/instantiation expressions.
Accept (parse) them but report a syntax error.
Adjust go/types and tests as necessary.
Change-Id: Ifc783245a54d276eb22232a7a74be4d47a7d33fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/250718
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When the printer mode UseBrackets is set, use the new unified parameter
list syntax: use []'s for type parameters without the "type" keyword.
This will also change gofmt behavior accordingly.
Fixes#41053.
Change-Id: Ibaf490ea9ed178684bea34da5b57afa823a6829f
Reviewed-on: https://go-review.googlesource.com/c/go/+/250998
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Type and ordinary parameter lists use the same syntax except
for the square brackets or parentheses, respectively.
Change-Id: I6fb93e93bbfc649a2c1ef195d130e0dcee212c79
Reviewed-on: https://go-review.googlesource.com/c/go/+/250717
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- use square brackets for type parameters
- otherwise, use same syntax as for ordinary parameters:
all type parameters must have a constraint, can be "any"
- remove (rename) all *B.go2 tests in favor of adjusted *.go2 tests
- remove tests related to pointer notation for type parameters
(we are going to use constraint type inference instead)
- adjust type string computation accordingly
- minor related adjustments
This change can be reverted if we don't like it.
Change-Id: Ie1034e0996df8f5ca6fbdf9ecaa3c93fcfd7106d
Reviewed-on: https://go-review.googlesource.com/c/go/+/249741
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
If UnifiedParamLists is set, type parameter must follow the syntax of ordinary
parameter lists except that they use square brackets rather than parentheses.
Change-Id: Ia17753eab2ab07e9ef62715a7b97d641f7d08cca
Reviewed-on: https://go-review.googlesource.com/c/go/+/249740
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Constraint type inference was not enabled for go/go2go and gotype.
Fixes#40859.
Change-Id: Idcab4d0a2eae6f42f938604fb05aabe4ad94c934
Reviewed-on: https://go-review.googlesource.com/c/go/+/249737
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a rewrite of the tests 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: I9cd097b8db2aa3c84a40a7aeaa10246ab3b990dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/248897
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
Robert Griesemer
Ian Lance Taylor
tdakkota