Nullability constraints should not be chosen when proper
argument constraints for variables in contravariant position present.
^KT-32106 Fixed
^KT-33166 Fixed
Prevent stack overflow during uncapturing of star projection
for parameter with recursive upper bound.
Uncapture star projections for flexible type parameters with
respect to flexible upper bound.
^KT-35210 Fixed
Variable with complex dependency on other variable loses its
original constraint position when variable it depends on is fixed.
To prevent that, original input position is saved in incorporation
position.
Check worked incorrectly in case when argument type and expected type are the
same intersection type, which is possible for local variables without explicit
type declaration.
Call checker and declaration checker are used in order to preserve backward compatibility.
Attempt to use classifier usage checker was not good enouth,
since not all errors found with it would actually be reported before.
For example types and constructor calls don't cause supertypes to resolve,
so missing supertypes would not lead to errors in case they are the only use of class name.
Updated tests failing due to missing Java dependencies in superclasses.
#KT-30297 Fixed
#KT-32168 Fixed
#KT-27722 Fixed (actually, it was fixed with addition of DefNotNullTypes, and now test was added to save this behavior)
#KT-32345 Fixed
They are currently marked as defined even when they get a
default implementation. That makes it hard to figure out
if the accessor should be removed when introducing a backing
field in the JVM_IR backend.
There are no `DEBUG_INFO_MISSING_UNRESOLVED` diagnostics for this test
if one runs it under LV=1.2. These diagnostics are not crucial
for the test (especially for version 1.2), so use it only with
the latest stable version
Plus, reuse test-data to check behavior in new inference
This call have interesting rules for resolution, see
`KtQualifiedExpression.elementChain` function and it's usages:
resolution results for such call can be omitted and be replaced with
some other information, while diagnostics will be reported from
builder-inference.
To mitigate this problem, we'll just skip this call from builder-inference
as such calls can't have type parameters anyway
#KT-32094 Fixed
Also that commit removes usages of builtins inside
effect system and starts refactoring of functor
composition via composition instead of inheritance.
There are some changes in testdata related to inference of recursive
functions with implicit return types.
After this commit they all are marked as unresolved. It happens because
those functions have DeferredType as return type, and computing this
type produces recursive exception, which provides “typechecker
recursive problem” diagnostic.
Before this commit, function call was completed successfully, because
call completer didn’t computed that type, and computation of DeferredType
were triggered only in `DataFlowAnalyzer.checkType`.
Now, effect system tries to compute that type while wrapping KotlinTypes
into ESTypes, and effect system itself is triggered in in call completer,
so, call completion doesn’t finish and function call is marked as unresolved.
#KT-31364
simon.ogorodnik