Type parameters are now collected as part of signature type
checking, as they are part of the type not the object. This
opens the door to more uniform handling of type parameters,
also for concrete methods and interface methods (future use).
Cleaned up confusion between Signature.mtparams and tparams:
tparams are explicitly declared function type parameters.
mtparams is gone and replaced with rparams which are the
receiver type parameters used in the function.
Various related cleanups.
Change-Id: Id8422b57cc8fbc18ffdca12a69d890aef83c3f80
A signature that's instantiated but doesn't have any incoming
or result (value) parameters doesn't get a copy automatically.
This leads to bugs because the instantiated signature doesn't
lose its type parameters when it should.
Make a copy outside for now, this fixes some (but not all cases)
and added test cases.
Also, factored out printing of type parameters in type printing.
Change-Id: I0ec3a4226c7473cddfb16704a2218992dd411593
This change completes the prior change by adjusting the go/types
implementation accordingly. As a consequence, contracts may now
not occur in type context anymore and errors are reported if they
do.
With this change, all tests pass again.
Change-Id: Id984b3d24b7cb6ff2fceb74fd3c33fd0af91fdce
Progress snapshot.
This change makes a contract declaration a proper declaration (as it is
envisioned in the design draft). Specifically, contracts cannot be used
in type position anymore, and a contract declaration is not treated as
a type declaration with the type being a contract.
The change has not been pushed through go/types yet; this change will
temporarily brake go/types.
Change-Id: Ia4034caebab07dac449a02cdd362d6ce5d61c4a3
Once a generic function is instantiated, it's not generic anymore.
Also: Added various additional test cases.
Change-Id: Ic2304b6c252cfdf41e526825dda64b8a77023d47
The new lazy method substitution code seems to work. The bug was
in the test, not in the implementation!
Change-Id: I39794743a01e9725d57f49ccd7c3751376cd01d6
When instantiating a type, we should also instantiate its methods (at least their
signatures) so that they have the correct type when being looked up. Unfortunately,
methods may not yet be type-checked; and worse, when we type-check them, typing
their receiver means instantiating that type again which would require updating
(= instantiating) the methods...
Instead, we keep the original list of methods (*Funcs) with each (named) type
and only update the method signatures when looking them up. The problem with this
approach is that we need to know with which values to substitute the method (i.e.,
receiver) type parameters, and this is currently not working.
Change-Id: Ie1835919dc8bfb8161a6a9e3d784c3bbbeb958c4
This CL introduces an update mechanism to customize method signatures
with the correct type parameters before comparing them for equality.
The mechanism is not correctly used, yet.
Change-Id: Ib88af88e151578a3fb3a648ed70d3f462a936c9b
When type-checking contracts, construct a parameterized named
interface for each of the contract parameters. Use those iterfaces
as type bounds for the type parameters.
This simplifies and cleans up the implementation.
Change-Id: I688e38542fa7fa83dd436439dd9ebe35af2f0458
Context-specific customization of parameterized interface methods of
type parameter bounds is missing; as a result some of linalg.go2 fails.
Change-Id: I3e749ee040d2b3ae8f73ae26680984bc1b4b79ef
If the type argument is itself a type parameter, we must use that
type parameter's bound to check against the bound of the type
parameter matching the type argument.
Change-Id: If5128115a9fc10af8163c37b1f75645447ead766
- type instantiations checks parameter count
- better positions for error messages
- removed some (now) dead code
Change-Id: Icf70642bbfd4e45a7762b002ea94704dc3d56475
This (temporarily) disables the use of recursively defined
generic types w/o repeating the type arguments, but such
type definitions need some more (type-checking) love anyway
before all conditions are checked.
Change-Id: I173f5ce2296b1c484ac95a3a887812c0b1f88245
- print type bounds when printing function signatures
- store (named) tyep bound rather than underlying type
- first example using parameterized interface type bound working
Change-Id: Ic7110039d1e09838c8f33040e887e6a4f038d75d
Accept (parse and type-check) parameterized interfaces with literal
type constraints, as in contracts. For instance, instead of
contract C(T) {
T add(T) T
T int, string
}
one can write
type C(type T) interface {
add(T) T
type int, string
}
Their use as type bounds still needs some work, though.
Change-Id: I9d59681dc0ba38054ee5627be141fc6e8a78381b
- set correct token position for ast.ContractType
- print "best effort" interface position in "complete interface" traces
- don't print trace output for types that are already set up
- print contract "signtature" when printing Contract type
Also: rebased on top of today's master branch
Change-Id: I6a528ce51a4152c25ad5d83ad52e01df8e89d283
This change expands type inference to parameterized named types
and clarifies handling of type parameters during type inference
(specifically, an inferred type may be a type parameter itself).
The change also implements method selectors with parameterized
receiver types by using type inference to deduce the receiver
type parameters.
Add more tests and enable many disabled tests that now work
correctly.
Change-Id: I8e10f9166fec9a8454f14b8fb089230c70422a1b
Also: disabled aggressive rewriting of methods upon type instantiation
(Need to first figure out what we really need to do.)
Change-Id: I6fba78d60963534ebfe130164058ac1fbed7e5a3
Robert Griesemer