Introduce invalidated flag to program producer to control whether to
only process invalidated nodes in incremental mode.
Update validated flag in RulesPlanHandler to reflect the finalized
state, after the plan has been built.
Refactor ProgramProducer/Factory to avoid enumerating the source
root in case no changes have been detected (in incremental mode).
Avoid relaunching program in case the producer did nothing.
Enable rule index to be updated during rules application.
Make RuleProcessingSession depend on AspectClique.
Enable updating of rule/macro/query indices.
It's important that program that uses occurrences from cache
shouldn't include rules that could produce their duplicates.
So implementation of occurence cache includes 2 parts:
on reactor level & in ProrgramFactory.
When RuleBuilders are produced, cache is queried whether
there're already occurrences associated with the rule template
in question. If so -- then those RuleBuilders are not included
into the program (as well as all RuleBuilders required by it).
Get information on invalidated nodes from EvaluateStep & incr processing
instead of UpdatesRecorder, which has only partial info and can't handle
all cases.
Consolidate options, configure all from typechecking plugin.
Introduce a computable option to control using traces.
Introduce shared state to be used at generation time.
Drop repository cache holder, replace with a field in state.
Fix singleton type collector.
Fix memory leak in strategy by cleaning it up after execution.
Ensure the order of rules in the resulting plan follows the priorities
set forward by extends relationship b/w languages. So that even if
rule template tables are unrelated, they are still ordered according to
language extension graph.
Ensure the order of rule lists in the resulting plan is stable b/w invocations of
RulesPlanHandler.allPlans().
Ensure the order of aspects in AspectClique is stable b/w invocations
of buildClique().
Associate RuleTemplatesTable with Manifest, and Manifest with CoderulesAspect.
Tentatively rename RulesList (the runtime object) to RulesPlan,
RulesListTable to RulesPlanHandler.
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.
Fedor Isakov