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
Term constructor creates all features with default values where
not overridden. The default values for "value" and "child"
features are wildcards for now (TBD), the default value for
list feature is an empty list.
The rationale is that a rule's head defining term pattern with
a logical variable capturing list feature will not be matched
with a free logical variable. Thus, to avoid having to always
explicitly specify all term features, a term constructor that
is not a pattern must use the default values for non-overridden
features.
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.
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)
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])`.
Expand macro supports dispatching by concept.
Logical variables declared on macro's body are init'ed in apply method.
Enable the hack to ensure dependencies on macro input are tracked.
Macro table can extend another macro table. All prototype template
declarations are imported automatically.
The editor now substitutes default values when entering new
expand macro/constraint filling the slots provided by the prototype.
Expand macro does not require name.
Minor editor improvements.
Expand macro template must have declaration of logicals matching
exactly the logical declarations in the prototype.
Can't refer to logicals declared directly in the prototype.
Parameters can be specified for call macro only.
Logicals can be specified for expand and call macro.
Expand macro params are treated exactly as "context"
parameters.
The old expand/call constructs are to be replaced by these.
Expand macro constraint refers to a named prototype, which
is specified in a macro table for matching concept.
Call macro constraint refers directly to a macro template.
Contex parameters are to be retired and explicit
parameters to expand macro constraint are to be used instead.
ExpandMacroTemplate to be used for dispatching macro invocations
based on the concept of the specified node.
Prototype is an abstraction to be implemented by
specific templates.
Call macros are to be parameterized with logicals and other parameters.
To replace combined expand/call macros causing confusion.
Context parameters to be passed explicitly.
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.
Rules that are used only as auxiliary resolvers don't have an associated
origin node, even though they are produced from a specific location.
To enable tracking of correct origin to report errors to one can use
origin(no origin){} to override the default behaviour.
Every node pointer (SNodeReference) specified as an arg to a constraint causes the (resolved) target to be included
into template application session (required).
Reduce NodeAnchor to .pointer call.
Deprecate Reporting interface and context repository in rule definitions.
Stronger rules for logical variables scope: constraint rule can't reference logical variable defined in another constraint rule. Logical variable definitions are localized to ConstraintRule template.
Simplify/cleanup the logic of searching for available logical variables.
One should be able to report issues with a target.
The target is normally inferred from the rule's origin, but sometimes it is
necessary to specify the issue's target explicitly.
basetag() returns name of ConstraintRule without node id.
Check on whether Rule is principal are now done through basetag(), it's sufficient.
Add part of future analysis: CallerTableBuilder.
Fedor Isakov