ExpressionLogicalVariable is replaced with ExpressionItem wrapping
the same expression.
Fixes ensure correct application of transformations.
Late expression can't be used as "placeholder" logical item.
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.
This is an important change in coderules syntax: all expressions to be evaluated from
constraints/predicates are to be wrapped in parentheses and preceded by dollar sign.
So, instead of eval/backticks the new syntax is to be used: $(<expression>).
Also the expressions to be passed to "feedback reporting" predicates are to be wrapped similarly.
Now principal rule head must include only principal constraints or be empty.
Without this restriction journal may include stale chunks which have no information to invalidate them.
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.
It is a rule-local, non-interprocedural analysis and it also uses VarAnalysisUtil.
New analysis checks whether free variables can "escape" principal constraint rules inside principal constraints.
If there is such escaped variable, then it is a signal that this type system is designed with non-local type inference in mind.
Otherwise there's no need to produce principal constraints with free logicals as arguments.
So, no principal constraints with free vars -- no type inference is possible.
Fedor Isakov