Also: Recognize method expressions with parameterized receivers
and report an error for now (not implemented yet).
Change-Id: I96405b2b739d8e9fff6e9840347d3e78bfe8b6ec
To make the import work, the import needs to be changed into
`import "./chan"`, the file testdata/chans.go2 needs to be
copies into a new directory testdata/chan and the file must
be renamed to chans.go.
But this exposes some problem with instantiating parameterized
types with other type parameters. Delaying this for now.
Change-Id: I1cd784fb89c2374131f3b1105493492eb0189abc
... and various related smaller fixes
We can now type-check the slices, chans, and maps
examples from the design doc (with the maps example
prodcing an error because importing chans doesn't
work yet). Progress!
Change-Id: Ifc00359a9a1cdad3bde1659a7de2028ac2544469
- moved type parameter collection out of resolver and into decl phase
- collect (meta-) type information (contracts) for type parameters
- first cut at checking contract satisfaction (methods only for now)
Change-Id: I46707969a172423738171aaea9d5282fb4b25a44
- collect contract methods in respective interfaces
- basic checking on contract type constraints
Contracts are not yet tested against or used to type check
function bodies.
Change-Id: I13b00c44524e599f92f1ba5b4b5d6734e2bf22e1
- type parameters can be printed
- empty contracts can be printed
- contract constraints are missing (only started)
Change-Id: I787898203aeb064b0b2ac49a7b858313cee5f45b
Also: Added -h flag to test framework; setting -h causes a panic when
an error is reported (for debugging).
Change-Id: Ib45d4ef38769f2ecdd3ce53fa3aed9fd99ef6bc8
Next known issue:
type List(type E) []E
var _ List(List(List(int))) = [](List(List(int))){}
This won't work because the RHS's composite literal type
is not fully instantiated - it has non-instantiated elements
which are ignored by Checker.instantiatedType. We could just
call Checker.subst w/o any parameters and have it walk the
incoming type and instantiate any element Parameterized types
but that is expensive and also appears to lead to stack over-
flow. Need to investigate.
Change-Id: I80bd09ab5f06e3991f198965424ce3322c7d6402
testdata/typeinst2.go has some complex examples that pass now.
But code elsewhere seems broken. go test has some issues at the
moment. Committing anyway to not lose the snapshot.
Change-Id: Id8f753a7b098405e2580a45ca1707ef6476c198e
- use the right type when instantiating a type
- substitute defined types when underlying types are changing
- improved printing of parametrized types
- improved printing of instantiated types
- more top-level trace output
Change-Id: Ie8a65c9cc51e80925d3f580f54dcc6c0b5abe4c6
- move init and method parameter checks to resolve phase as well
- more consistent error messages
- more tests
Change-Id: I6cb147b35385541ca5d7d7e3f87159df84cced76
Updated go/ast and go/parser. go/types doesn't process the
new data structure yet and is missing a good type representation
of contracts.
Change-Id: I101f7c9e98008840dd1edb55404bb97db5a66ccd
Additionally, simplify the syntax for contracts specified in a
type parameter list: It is now not possible to provide explicit
type parameters to a contract in a type parameter list - they
are always implicit. For instance
func f(type P1, P2 C(P1, P2)) ...
must be written as
func f(type P1, P2 C) ...
If a different order or different types are desired for C,
a new "intermediate" contract must be declared, as in
contract C'(A, B) {
C(B, int) // here we allow type parameters
}
func f(type P1, P2 C')
This simplification will remove confusion if we decide to
allow individual contracts in type parameter lists, such as
func f(type P C, P1, P2 C') ...
In this case, C accepts one type parameter (and applies to P),
and C' accepts two type parameters and applies to P1 and P2.
The simplification avoids questions such as whether this code
should be permitted:
func f(type P C(P2), P1, P2 C'(P, P1)) ...
(i.e., can pass P2 to C, or P1 to C', etc.)
This change switches parsing back to using () parentheses for
type parameters. The parser now also accepts contracts in
parametrized type declarations, and top-level declared
contracts as defined in the design draft:
contract C(T1, T2) { ... }
(Internally, they are mapped to an ast.ContractType as before.)
Added more tests, incl. map.go2 from the design draft, and removed
some unused parser functions.
Passes parser and types tests.
Known issue: Composite literals with instantiated composite literal
types are not recognized properly: T(P){...} fails to parse.
This change implements parsing of contracts based on the
most recent design (using a combination of methods and
explicit basic types as well as the short-hand notations
0, 0.0, 0i, ==, and !=). At the moment, a contract is
considered a "type" and declared as such:
type C contract(T1, T2) { ...}
This change also implements parsing of type instantiations
and type parameters for type declarations, using both the
() parentheses and [] brackets (if the flag useBrackets is
set in parser.go).
Not all parsed data structures are set up correctly in the
AST yet. The parser and ast tests pass.
Change-Id: I11ce64ad49e404c5a66ce6623edc8313e803e135
This change implements parsing and type-checking
of parametrized functions (without contracts).
Type-checking includes checking of generic function
calls using explicit type parameters as well as
implicit type parameters inferred from the actual
arguments.
Change-Id: I03c9c6912aa1e2ac79d9c5125fd5ac72df4e808a
This alert is triggering occasionally. I've investigated the
collisions that happen, and they all seem to be pairwise, so they are
not a big deal. "pairwise" = when there are 32 collisions, it is two
keys mapping to the same hash, 32 times, not 33 keys all mapping to
the same hash.
Add some t.Logf calls in case this comes back, which will help isolate
the problem.
Fixes#39352
Change-Id: I1749d7c8efd0afcf9024d8964d15bc0f58a86e4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/237718
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Support for linux/386 was added to Delve in version 1.4.1, but the
version of Delve currently installed on the linux-386-longtest
builder is 1.2.0. That isn't new enough, which causes the test
to fail. Skip it on that builder until it can be made to work.
The only reason it used to pass on the linux-386-longtest builder
before is because that builder was misconfigured to run tests for
linux/amd64. This was resolved in CL 234520.
Also improve internal documentation and the text of skip reasons.
Fixes#39309.
Change-Id: I395cb1f076e59dd3a3feb53e1dcdce5101e9a0f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/237603
Reviewed-by: David Chase <drchase@google.com>
We replaced http.DefaultClient with securityPreservingHTTPClient,
but we still need that too many redirects check. This issue introduced
by CL 156838.
We introduce a special path to test rediret requests in the script test
framework. You can specify the number of redirects in the path.
$GOPROXY/redirect/<count>/...
Redirect request sequence details(count=8):
request: $GOPROXY/mod/redirect/8/rsc.io/quote/@v/v1.2.0.mod
redirect: $GOPROXY/mod/redirect/7/rsc.io/quote/@v/v1.2.0.mod
redirect: $GOPROXY/mod/redirect/6/rsc.io/quote/@v/v1.2.0.mod
redirect: $GOPROXY/mod/redirect/5/rsc.io/quote/@v/v1.2.0.mod
redirect: $GOPROXY/mod/redirect/4/rsc.io/quote/@v/v1.2.0.mod
redirect: $GOPROXY/mod/redirect/3/rsc.io/quote/@v/v1.2.0.mod
redirect: $GOPROXY/mod/redirect/2/rsc.io/quote/@v/v1.2.0.mod
redirect: $GOPROXY/mod/redirect/1/rsc.io/quote/@v/v1.2.0.mod
the last: $GOPROXY/mod/rsc.io/quote/@v/v1.2.0.mod
Fixes#39482
Change-Id: I149a3702b2b616069baeef787b2e4b73afc93b0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/237177
Run-TryBot: Baokun Lee <nototon@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This API and functionality was added late in the Go 1.15 release
cycle, and use within gopls has revealed some shortcomings. It's
possible (but not decided) that we'll want a different API long-term,
so for now this CL renames UsesCgo to a non-exported name to avoid
long-term commitment under the Go 1 compat guarantee.
Updates #16623.
Updates #39072.
Change-Id: I04bc0c161a84adebe43e926df5df406bc794c3db
Reviewed-on: https://go-review.googlesource.com/c/go/+/237417
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>