Fix rule basetag generation to coincide with templateName
Needed for PrincipalStore (occurrence cache) which uses
info about occurrence source rule template name.
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).
Refactor whe way TypecheckingResultsCache is updated:
all mutatiting methods extracted to Update subclass, which is
only available to the updater.
Make TypecheckingState a regular container for (unit) caches.
Make TypecheckingService responsible for managing caches.
Extract TypeModuleOwner and TypeModelHandler classes.
Get rid of QueryResultsCache, merge into TypecheckingResultsCache.
TypeModuleOwner to manage "repository" cache.
Now whether unchecked conversion is allowed is controlled
by ConvertsContext.Options of convertsTo relation.
Introduce 'erased()' term to be used in raw type params.
Drop 'uncheckedConversion' parameter in all macros.
Classifier kind:"raw" is now used only for Recover.
Allow unchecked conversions by default. Forbid for sequences.
Can't properly handle this case now.
To handle this case of no type of initializer in assignment context
need to discern cause of this "no type". If it's because of error --
then can't assign to it any type. If there were no error
(e.g. case of test) -- then type can be inferred from assignment ctx.
Anyway it's not very important corner case, can leave this test relaxed.
TypecheckingService and provider component are explicitly dependent
on SRepository.
The repository instance comes from the first opened project, which
is a dirty hack and is temporary until Typechecking Facade API
is fixed to provide appropriate instance.
Hierarchy graph vertex can represent LUB as a simple
collection of inheritance paths.
Abstract intefaces allow to model operations such as finding
the LUB in an abstract way.
Greatly simplify code.
Motivation is that implicit (non-overriden) list features must unify
with list of any length. Consider an example:
`classifier(cls: node-ptr/A/) = classifier(cls: node-ptr/A/ param: [B,C])`
With previous approach it would fail, which seems counter-intuitive to me.
So, if empty list (e.g. of type parameters) is meant, then it must be
specified explicitly.
There's one thing to remember, though: such wildcard list features
won't match with MetaLogicalArrays in rule heads.
(e.g. see dpromote_* rules and consider what happens when
a classifier with unbound `parameter` feature comes in)
Introduce common 'parameterized(child typeParams)' term
to allow unifying processing of GenericDeclarations.
Collect type variables from enclosing GenericDeclaration.
Will be needed to simplify instantiation of nested generic decls
(e.g. generic method inside generic class) using `genDecl`
machinery instead of TypeVarSubstitution.
Fedor Isakov