UnitTypecheckingCacheHolder now holds the data needed for ChangesTrackers.
This data is updated by UpdatesRecorder: different models and nodes from different roots are tracked.
SNode is supported now directly as an argument to constraint/predicate.
Pointer operation is no longer necessary, as is node-ptr<> type for logical vars.
Previously there were two independent ChangeTracker-s in UpdatesRecorder and UnitTypecheckingCacheHolder.
Now, given more elaborate logic for tracking changes to types (which includes changes in different roots)
this information must be propagated from UpdatesRecorder to cache holder,
so that if there're changes relevant for recomputing types then types cache is also invalidated.
To avoid confusion, a rule defines "target ref", which is supposed
to indicate the source code location for possible errors.
The origin node is to be referred as "origin" as before.
Temporarily rename OriginSpec's alias to "target" to reflect change
in semantics.
LogicalItemValueExpression is to play the same role as valueOf(logical)
within an instance of EvaluationSubject.
LogicalItemExpression is to represent the logical variable itself.
TypesIndex now invalidates report items from previous sessions not by node refs,
but by tags of rules which produced them. Set of invalidated tags is an addiitonal
output from incremental engine.
TypecheckingQueries must track the types index used for reporting
the state of cache, since the index itself is built independently
of whether or not 'checkRecursively' is invoked.
Introduce SessionData, allow to keep arbitrary data with the session.
Extend RulesListTable with support for invalidation based on rule unique tags.
Introduce UpdatesRecorder to keep track of invalidated nodes.
Extend ApplyTemplatesStep with invalidate logic for typechecking.
Simplify design, drop unnecessary fields, minor refactorings.
The inferred type can be either capture or type variable.
This logic is covered by a new rule 'inferFromCapture'.
For examples see 'Bounds' test sample.
This inference is used in call arguments type inference.
It happens on cases when bounds arise from several places:
(a) bounds for inference variables from type vars declared in method signature (hasBound constraint)
(b) bounds of type vars used as arguments to call (typeVariableType term wiht bounds inside)
(c) bounds from captures on type variables from case (b), which come in the form of 'captureOf' term
Grigorii Kirgizov