Hierarchy graph vertex can represent LUB as a simple
collection of inheritance paths.
Abstract intefaces allow to model operations such as finding
the LUB in an abstract way.
Greatly simplify code.
Now rules concerned with generics handle type vars from enclosing scope.
Complete typechecking of BaseMethodCall: consider static/nonstatic cases.
Complete typechecking for class creators, handling type vars from cls & ctor.
Refactor rules for EnumConstantDeccl & ClassifierType.
Related to MPSCR-20 & MPSCR-29.
Motivation is that implicit (non-overriden) list features must unify
with list of any length. Consider an example:
`classifier(cls: node-ptr/A/) = classifier(cls: node-ptr/A/ param: [B,C])`
With previous approach it would fail, which seems counter-intuitive to me.
So, if empty list (e.g. of type parameters) is meant, then it must be
specified explicitly.
There's one thing to remember, though: such wildcard list features
won't match with MetaLogicalArrays in rule heads.
(e.g. see dpromote_* rules and consider what happens when
a classifier with unbound `parameter` feature comes in)
Introduce common 'parameterized(child typeParams)' term
to allow unifying processing of GenericDeclarations.
Collect type variables from enclosing GenericDeclaration.
Will be needed to simplify instantiation of nested generic decls
(e.g. generic method inside generic class) using `genDecl`
machinery instead of TypeVarSubstitution.
Observing the invariant: whenever a constraint is used in
rule's head, the rule table containing it must extend the
one that constraint.
Also drop unused constraint from the head in ConversionFunctionIFace.
Mainly, avoid extending TypeOf by ConversionMain (unnecessary dependency).
It's also more logical structure: tables defining declarations go first, then typeOf-related.
So rule tables which require only decls can depend only on such tables.
Core tables extends relationship now:
TypeBound <- CheckAll <- Generics <- TypeOf
TypeBound <- ConversionMain [<- other langs' conversions]
As closures typesystem depends on collections due to sequence type,
so collections typesystem depends on closures due to function type.
E.g. consider typechecking of SequenceCreator.
Fedor Isakov