Rule's unique_tag is important for update procedure
implemented by RulesPlanHandler. Only when we can guarantee
that an argument to constraint/predicate has not changed
we can save on re-building a rule from template.
Ignoring LateExpression was a mistake.
While check/checkTypeOf queries are required to
process a whole root, other types of queries
can be sensitive to what aspects to include in
the processing.
Aspects are sorted in strongly-connected components,
among which the relevant one is selected.
The deisgn decision to have only one instance of QueryTemplate
leads to the necessity to keep AspectClique separated for
every "typesystem". Whereas QueryTemplate are really perfectly
composable, and thus only one AspectClique is neeeded.
Also drop a rudimentary unused feature.
Instead of the hack that that uses session parameters to pass
parameters to expandMacro, use directly `withParams` method
on macro token. All parameters are mapped to corresponding fields.
Introduce CustomSessionParameter to access parameters in
TemplateApplicationSession.
Expand macro passes the rule's input to nested macro calls.
This adds the macro input as the dependency of the rule's input.
As a result, incremental processing starts working in some cases.
Invalidated rules set invalidates feedback that has any of them it in its basis.
Validated rules invalidates feedback that has all of validated
rules in its basis set.
Enable recording the dependencies while expanding macro.
Rename/refactor operations in UpdatesRecorder to reflect the intent
of adding the dependencies.
Some language imports necessary for correct typechecking are obscure.
Example may be a closure type, which requires the type of the operand
(receiver) of the method it serves a parameter to. That, in turn, may
require some type defined in another root and perhaps some other model.
Fix rule basetag generation to coincide with templateName
Needed for PrincipalStore (occurrence cache) which uses
info about occurrence source rule template name.
It's important that program that uses occurrences from cache
shouldn't include rules that could produce their duplicates.
So implementation of occurence cache includes 2 parts:
on reactor level & in ProrgramFactory.
When RuleBuilders are produced, cache is queried whether
there're already occurrences associated with the rule template
in question. If so -- then those RuleBuilders are not included
into the program (as well as all RuleBuilders required by it).
TemplateApplicationSession allows to invoke require with the
input node as the first parameter, which is then forwarded as
a "requirement" (TODO: rename to dependency).
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.
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<>.
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.
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.
During template application memo can be used to store results
of a computation in the session. The memo will be automatically
cleared on an event that invalidates the caches.
IncrProgramSpec influencing program eval is built from two sources:
internal analysis results & typechecking options.
Providing spec builder instead of spec allows to combine these
sources later at program pipeline creation in TypecheckingService.
Commit accomodates to addition of IncrementalSpec.Enabled.Unsafe
Commit also simplifies ProgramAnalysis -related classes.
Renames BasicProgramAnalysis to PrincipalsAnalysis.
Operations such as 'error' and 'warning' are available on input
node in templates and serve to report issues found during
template application, in contrast with those found during evaluation.
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
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).
Fedor Isakov