The idea to use "tracking" cache to save on typechecking operations is obsolete.
There is conflict of responsibilities with UpdatesRecorder,
which is to be solely relied upon for all things related to tracking changes.
StyledTreeCellRenderer component received wrong bounding box
because of top border's inset to be set to 1 (see DefaultTreeUI.paint()).
This border is the default set by LookAndFeel.installBorder()
in case the border on tree component is set to null,
which is explicitly set to null in TreeTableTree's constructor (go figure).
Support Type type.
Simplify depdendency of var decl to its type.
Covariant subtyping for UpperBoundType.
Straightforward dependencies on type's parameters.
Specify BaseConcept as general type's concept.
Fix method reference.
This particular extends clause breaks an internal invariant
of rules plan, namely the topological sorting of rule tables.
This results in broken rule index, which needs to be fixed.
Also, disable a suspect rule that relies no typeof()
*not* being present, which is a transient condition.
A problem with collections language is that linkedlist type
gets generated into a Deque. There is a workaround for this,
which fails to work because of another problem in collections
language: linkedlist not being a direct subtype of LinkedList.
Probably a legacy code issue.
Some language imports necessary for correct typechecking are obscure.
Example may be a closure type, which requires the type of the operand
(receiver) of the method it serves a parameter to. That, in turn, may
require some type defined in another root and perhaps some other model.
Enable rule index to be updated during rules application.
Make RuleProcessingSession depend on AspectClique.
Enable updating of rule/macro/query indices.
On looking up the default functional classifier corresponding to a
function type, the classifier's type parameters are to be appropriately
populated from the function type.
Fix rule basetag generation to coincide with templateName
Needed for PrincipalStore (occurrence cache) which uses
info about occurrence source rule template name.
Allows to carry logically connected information in one object.
Needed for subsequent changes to ConstraintOccurrence, which
must have better information on source rule: rule template name.
Used by occurrence cache.
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).
CachedOccurrencesProcessing simply activates occurrences
passed to it as input before proceeding with 'main'.
Use it instead of PreambleProcessing (that works with journal).
This should help if 'main' doesn't lead to duplicate activations
of these occurrences. So coderules program must be aware of
occurrence cache and should not include rules for cached occ-s.
Fedor Isakov