Matching on two constraints without an "anchor" (origin)
is essentialy quadratic. On a large root there may be
many typeof/expectType instances and it slows down the
computation considerably.
In with the above flag set to false a conversion of list<T> to list (raw type)
fails, because the latter is represented as list<Object>. (T is any type).
This situation usually arises from queries like coerce(T to concept=ListType).
It was aimed at precluding cascading typechecking failures.
(There was some case with typechecking 'hasBound' after incorrect bind.)
It seems controversial. Typechecking with it is no more predictable
than with free variables left unbound in case of error.
With current tests almost nothing changes after removing it.
These unused in bodies constraints were for tracking certain
cases of incremental dependencies. Now it's handled by minor
algorithm extension introduced in several previous commits.
Fixes IncrClosureInference.changeFunctionalInterfaceParam test.
Temporary rules built as macro applications weren't computing hash
due to origin!=null condition. Also macro inputs weren't processed.
Stable hash for TypeVarSubstitution is defined because it's used in macro args.
In general, any classes used as constraint/predicate/macro args
must adhere to stable hashCode() contract: hash should change
if there're important changes that may influence typechecking result.
Otherwise there may be unnecessary incremental recomputations.
Relevant for MPSCR-62
Add 'genDecl' constraint in heads of toFunctionalCls* rules
to handle incremental changes to respective classifier.
Also fail instead of just reporting error to break execution and
report on correct node according to calling rule.
UndefinedType should leave the logical variable unassigned.
Type is an abstract superconcept, so reaching it means
there should have an override for lift macro.
Replace unification with the intent of capturing term feature
with match constraint.
Drop unused term feature from head pattern.
Provide better context for failed class inheritance test.
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.
Grigorii Kirgizov