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
There is an inconsistency between old and new inference for storing
receivers of resolved calls. In new inference, for captured types,
receiver will be changed and to preserve behavior of the old inference,
we use original one during important checks.
This is more a workaround than a solution and should be revisited.
#KT-31356 Fixed
#KT-29948 Fixed
#KT-31360 Fixed
Use KotlinBuiltIns.isString instead of equality with
KotlinBuiltIns.string, which is more portable across different module
configurations. Also use isSubtypeOf instead of
DescriptorUtils.isSubclass and thus get rid of an extra error on an
unresolved class in nativeAnnotationCheckers.kt
Expression will be checked against expected type later.
Theoretically, this is not very good, but it aligns with the old
inference, plus it helps avoiding multiple type mismatch diagnostics.
In case Java enum has an abstract member, it has the ACC_ABSTRACT flag
set in the bytecode. However, we should still load it with final
modality to be consistent with Kotlin enums which are always considered
final
#KT-23426 Fixed
Since we skipped trivial constraint with `Any?` from parameter type of
function `equals`, the compiler thought that there is no proper
constraints (upper bounds do not matter here) and marked resolved
call as a failed one, then diagnostic about missing equals was added
Also, tune `TrivialConstraintTypeInferenceOracle` for `Any?`-like
constraints
#KT-30724 Fixed
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
Add `IntegerLiteralTypeConstructor` that holds types, that can take
integer literal with given value. It has two supertypes
(`Number` and `Comparable<IntegerLiteralType>`) and have
special rules for subtyping, `intersect` and `commonSuperType`
functions with primitive number:
Example (assuming that ILT holds Int type):
* ILT <: Int
* Int :> ILT
* ILT intersect Int = Int
* commonSuperType(ILT, Int) = Int
#KT-30293 Fixed
#KT-30446 Fixed
Mikhail Zarechenskiy