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
There was a silly bug: equal constraint is actually a lower and an upper
constraint, but we checked only presence of lower constraints.
Test is important as here we have one equal constraint and should
complete inner call `foo<Int>()` without propagating it to `bar` to
avoid using `NoInfer` annotation multiple times
These tests were added for suspend-conversions, it worked only
with new inference, but implementation was incorrect and had other
bugs, which were fixed in 1ac25259.
Support of suspend-conversions will be addressed later with a different
implementation (#KT-30703)
For functions with implicit return type annotations will be replaced
anyway in order to initialize return type, so this restriction in
`StubType` was too strong
#KT-30656 Fixed
Pavel Kirpichenkov