It makes definition of principal constraint clearer:
principal constraint is a constraint that has at least one arg
of type node<> and passes to it ruleOrigin in at least one rule.
Such constraints are most likely meant to define relations
of nodes to terms, e.g. `typeOf` -- which is what we're interested in.
At the same time semantics of values inside terms is less defined.
TermFeatures are also untyped, and so complete analysis of
ValueFeatures would require full code traversal of coderules program
to find out whether a value feature is used to carry smth of `node` type.
Relevant to MPSCR-62.
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.
Avoides the need to exactly duplicate features of ancestors.
Opens possibility to match on super-terms
with partially provided (overriden) features.
For example, suppose there's `typeParameterized(child: param)`
term which is extended by `classifier` and `methodSignature`.
Then it becomes possible to write a common rule for both terms,
matching on `typeParameterized(param=[Smth])`.
Treat a language and its sidekick (if any) as a single vertex.
Add all extended languages to the pool before building the graph.
Drop dubious invariant check.
Fix the second pass in findAspectCliques ingnoring the fact
that there might be leafs without aspects.
Now algorithm for finding aspect cliques includes 3 stages:
1) topological sort (as before)
2) bottom-up pass with initial assignment of clique ids (as before)
3) top-down pass (i.e. in reverse topo sort order) (added stage)
The 3rd stage handles case when hierarchy of langs with
required aspect include branching point (with no join further down),
as in the case of closuresExt & collectionsExt both extending blExt,
but unrelated to each other (neither extends the other).
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.
Fedor Isakov