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.
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.
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.
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