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.
Fix rule basetag generation to coincide with templateName
Needed for PrincipalStore (occurrence cache) which uses
info about occurrence source rule template name.
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.
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.
Match constraint is provided for use cases where the intention
is to pattern-match a term capturing features into logical
variables.
A term constructor in the right-hand side of match constraint
is a pattern, and all its non-overridden features are
to be defined as wildcards.
It's possible to activate constraints in macros, so they must be also handled.
Also restrict a bit principal rules analysis: consider only rules with template input.
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.
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])`.
Fedor Isakov