A query may be invoked without the input node, thus dispatching
macros by the specified concept. The concept must be taken into
account when calculating the "diff", so that the old (stale)
rules don't override the updated ones.
This query kind is to be used in local typechecking.
The idea is to do away with constraints that are not essential for
typechecking a single node, thus making local type computation faster.
Consolidate options, configure all from typechecking plugin.
Introduce a computable option to control using traces.
Introduce shared state to be used at generation time.
Drop repository cache holder, replace with a field in state.
Fix singleton type collector.
Fix memory leak in strategy by cleaning it up after execution.
Avoid dereferencing DynamicReference from OriginIndex as it involves typechecking computation.
Aviod enqueing type nodes with TypesModelHandler during generation,
a workaround for "mature" references unable to be resolved
if target is in a transient (unpublished) model. (MPS-32709)
Ensure "local" typeof computation is used when queries a created with null root.
Specifically treat convertsTo of LogicalType to ClassifierType, support
convertsTo classifier type w/o specified classifier.
Fix typeOf LogicalItemValueExpression by to rely on logical's type.
Accept LogicalItem in LogicalItemValueExpression's logical slot to enable
replacement of it with an expression at generation time.
Drop node-ptr in node features, macro calls.
Drop node-ptr types in rule templates and recover closures,
fix BiConsumer params
Drop node-ptr// refs where appropriate.
Drop pointer operations from macro calls and term ctor's; add resolve to FunctionTypeLookup static table.
Drop node pointer operations from constraints, add require statements in SModel types macro table.
It might be necessary to look a little further into the input node's
referenced nodes to gather all relevant models for recovering
types aspects. Example: a type in BL may extend another BL type
parameterized by a non-BL type, such as node<>.
When inferencing the type of a closure within a method call context,
it's important to strip occasional contravariant indicator from the
closure's input variable.
A method may declare its argument to be an SMI with the type(s) of
its functional method's arguments as ? super T to facilitate subtyping.
This must not affect the inferred type of the closure's input variable.
Ensure valid list of context type var decls is passed to
instantiateScheme macro.
The code in MethodCall needs to be fixed in order to respect
context type variables in case of instantiation of a non-static inner class.
Absence of "principal" flag on "main" contstaint causes invalid
processing of added rules that are triggered by this constraint.
Introduce protective copying of arguments in IncrProgramSpecBuilder.
The builder implementation must not reuse the collection passed in as argument.
Contract stems from the fact that constraint args influence Rules hashes (unique tags)
and so must be stable under irrelevant changes for incremental logic
Also process expand macro input for rule hash,
so that changed query rules (like one in testlang) get into
RulesDiff and could be updated with Preamble processing.
Introduced to discern incremental strategies: Full,Preamble,Default.
because how SessionToken is used and stored depends on it.
EvaluationSessionImpl now simply dispatches to it.
Also rename 'IncrementalProcessing' to 'ProcessingStrategy'.
Program Preamble consists of 2 parts: rules & Journal.
Preamble rules are no-input rules with rules for their required nodes.
Preamble journal is journal part with results of executing these rules.
Preamble is defined per-Query, because Journal differs for Queries.
Repository CacheHolder is used for storing them b/w sessions.
Rules are stored and retrievied with Memoizer.
Journal is stored as SessionToken in PreambleSet (map Query->SessionToken).
Add option to IncrementalSpec -- incrementality level (Preamble or Full).
Ensure the order of rules in the resulting plan follows the priorities
set forward by extends relationship b/w languages. So that even if
rule template tables are unrelated, they are still ordered according to
language extension graph.
Ensure the order of rule lists in the resulting plan is stable b/w invocations of
RulesPlanHandler.allPlans().
Ensure the order of aspects in AspectClique is stable b/w invocations
of buildClique().
Associate RuleTemplatesTable with Manifest, and Manifest with CoderulesAspect.
Tentatively rename RulesList (the runtime object) to RulesPlan,
RulesListTable to RulesPlanHandler.
Too many nodes get into tmpl application process, which is unnecessary.
Many of those nodes are required actually only for correctly tracking
changes to nodes with WatchingTypecheckingStrategy.
Now implicitly required only nodes which are mentioned inside
constraint arguments. In other cases user must require them explicitly.
Fedor Isakov