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
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
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
The problem is that delegated properties resolve two calls together:
`getValue`/`setValue` with a common receiver, which can contain
callable references. For each completion new anonymous descriptor
was created and caused "rewrite at slice" exceptions later.
Now there is a little hack to check that during one inference session
we don't complete one call more than one time.
More correct fix would be to explicitly specify common receiver for
inference session but it requires quite big refactoring, which will
be done later with a whole refactoring of the common solver
#KT-30250 Fixed
Consider common supertype of `S` and `Nothing`, where `S` has nullable
upper bound or it's flexible. Before the fix, result was `S?`, which
is correct but too conservative. Now, we'll preserve nullability of
resulting type if it's already nullable.
This happened because we were failing to find path of not-nullable
types from `Nothing` to `S`, which should obviously exists by
semantics of Nothing
Mikhail Zarechenskiy