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.
To fix them need either extending incr algo to handle rules which
postpone binding logicals in principal constraints (i.e. typeOf)
(see rules in Closures for 'invoke' expression)
or rewriting these rules to not produce typeOf with free logicals.
Add 'genDecl' constraint in heads of toFunctionalCls* rules
to handle incremental changes to respective classifier.
Also fail instead of just reporting error to break execution and
report on correct node according to calling rule.
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.
Grigorii Kirgizov