- implemented for comparisons for now
- can type-check generic min
- also: rebased on top of Go tip
Change-Id: Id35582a59c4cddcb2b4ae9c7d7154ef8e41580ab
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
Robert Griesemer