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>
Also, take type lists into account when computing predicate.
Addresses crash #27 of #39634.
Updates #39634.
Change-Id: Id6e1d0d86ac1cb9d79828a3b5fdfbeba0e6aace0
Reviewed-on: https://go-review.googlesource.com/c/go/+/240902
Reviewed-by: Robert Griesemer <gri@golang.org>
Addresses crash #20 of #39634.
Added test, also for some of the other cases that don't crash
anymore.
Updates #39634.
Change-Id: I999e376985a443ac435f64a7c249f891e7b7a6d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/240901
Reviewed-by: Robert Griesemer <gri@golang.org>
HasTypeList existed before but now is also written such that it doesn't
expect an interface to be complete.
Change-Id: I43e8d652c6be755473b201a64bf41d363214881c
Reviewed-on: https://go-review.googlesource.com/c/go/+/240719
Reviewed-by: Robert Griesemer <gri@golang.org>
If an embedded field is an instantiated type, we need to instantiate
it when instantiating the whole type, in case the type arguments
themselves need instantiation.
Fixes#39953
Change-Id: I80b57456aa4f8e8b2eff82359066c37a9c2a40f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/240522
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer
Ian Lance Taylor
Rebecca Stambler
Pavlo Bashynskyi