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.
The flag "recursive" is passed down to ProgramFactory to control whether
the input nodes are to be walked recursively.
This flag is set to false when calculating a node's type in isolation.
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.
Drop recording of "suppressed exception" by CoderulesHelper.
Report failed program evaluation as info message.
Ensure traces are available for failed evaluations.
UnitTypecheckingCacheHolder now holds the data needed for ChangesTrackers.
This data is updated by UpdatesRecorder: different models and nodes from different roots are tracked.
TypesIndex now invalidates report items from previous sessions not by node refs,
but by tags of rules which produced them. Set of invalidated tags is an addiitonal
output from incremental engine.
Introduce SessionData, allow to keep arbitrary data with the session.
Extend RulesListTable with support for invalidation based on rule unique tags.
Introduce UpdatesRecorder to keep track of invalidated nodes.
Extend ApplyTemplatesStep with invalidate logic for typechecking.
Simplify design, drop unnecessary fields, minor refactorings.
The inferred type can be either capture or type variable.
This logic is covered by a new rule 'inferFromCapture'.
For examples see 'Bounds' test sample.
This inference is used in call arguments type inference.
It happens on cases when bounds arise from several places:
(a) bounds for inference variables from type vars declared in method signature (hasBound constraint)
(b) bounds of type vars used as arguments to call (typeVariableType term wiht bounds inside)
(c) bounds from captures on type variables from case (b), which come in the form of 'captureOf' term
Config is an application-level "component" initialized from an application plugin.
All usages on application/project-level should declare explicit dependency on it.
Tests can either create a new instance or access the shared one.
Options providers are registed in application plugin and project plugin.
Application plugin registers the USER level options, project plugin
is responsible for UI level.
Option providers are cleard on closing project/closing app.
It's important to keep reference to the aspect clique that used to instantiate
a particular helper. Later it can be used to identify the correct session token.
A reusable Config app component to be responsible for all level of configurations: default/system/user/ui.
Swith to Config interface instead of map<string,Object> for options.
Add an UI option to control whether trace is enabled.
Refactor Effect: drop type parameter, simplify usage.
Redesign the way values are provided by an Effect.
Simplify schedule method signature.
Drop scheduleWithTrace from Step interface.
Introduce ConfigureEvalStep.
Drop Step.Options.
Drop LocalEffect's.
Grigorii Kirgizov