This commit is a hotfix rather then proper solution.
The source of the issue is that currently type variable fixation result
may change due to fixation order alteration for variables with the same priority.
For instance, having variables V1, V2, and proper types Type1, Type2, such that:
V1 <: Type1
V1 <: V2
Type2 <: V2
both variables will be fixed either to Type1, if V1 will be fixed first,
or to Type2 otherwise.
Since this limitation cannot be easily overcome, the taken approach is to remove
incedental constraint added after 2d5a0546 by restricting nullability constraint check
to `Nothing?` constraints only, thus postponing problematic variable fixation.
To clearify, additional constraint is correct and should cause no harm (in ideal world),
but currently its presence changes fixation order.
So without the restriction the previously used constraint from fixed outer variable
is no longer available by the time problematic variable type is being selected.
^KT-37043 Fixed
It's not clear how one should rollback _all_ resolution results if
there is inapplicable call. Ideally, such calls should not be available
in coroutine block but for now, to have backward compatibility, we'll
just reanalyze coroutine block as a usual lambda if there is at least
one such call.
As a result, also remove diagnostic about non-applicable call as it
become useless with current reanalysis
#KT-37061 Fixed
#KT-32097 Fixed
#KT-32203 Fixed
#KT-35306 Fixed
#KT-36202 Fixed
#KT-36220 Fixed
#KT-32654 Fixed
In this test `kotlin` was resolved to the extension
`val Class<T>.kotlin` because it was saved in builder-inference.
Usually, it's fine, but not for qualified expressions as they have
fallback resolve in case of error
Usually FIR enum entry is initialized by anonymous object,
which is the container for all enum entry' declarations.
However, for simple enum entries there is no need of initializer at all.
Call argument for conventional `contains` after expanding `in` may come from a `when` subject during its branch analysis.
In this case data flow info from a previous when branch was not considered,
because data flow info for subject had been used instead of data flow before argument.
Use of the latter one for the conventional `contains` solves the issue.
The old FE uses `isExternal` property of value arguments to skip smartcast reporting on `when` subject,
if they come from branches. To prevent undesired smartcasts on `when` subject after branch analysis in the new FE,
`isExternal` arguments are skipped in diagnostic reporter and during recorded type update.
Also, the new FE interprets `isExternal` completely differently from the old FE.
In the old FE this property is used exclusively by `when` with subject.
In the new FE it is also used for parially resolved calls, lambda return arguments and receivers.
This may be preventing the use of data flow info before argument in the first place, but this assumption requires additional investigation.
^KT-36818 Fixed
Previoisly, there were two places where mapping had happened:
- toConeKotlinTypeWithNullability
- enhancePossiblyFlexible
The first one was used for supertypes and bounds and the second one
was used for other signature parts
The main idea is to perform type mapping once to a flexible type,
and then use it as it's needed (it's lower bound, or for the further ehnancement)
Also, this commit fixes flexibility for type arguments, see the tests
See 62a55b7b00
Previously, it was working for O(n^2)
Now, we first group it by jvm descriptor,
then for each groups of size g_i finding the most specific for O(g_i^2)
It should help for the cases when we have a lot of overloads with
different JVM descriptors (modulo return type)
NB: Having the same JVM descriptors is rather rare, because
in Java one cannot generate such a class.
Looks like it's only possible for Scala or some other JVM languages (KT-17560)
It should help a lot for KT-35135
Full completion should not be done if lower `Nothing`
is the only proper constraint when constraint with ILT type is present.
ILT will be selected as a resulting type and transformed into `Int`
without attention to possible restrictions from outer calls.
`isNullable` check returns `true` for flexible types,
which leads to false positive unsafe invoke error, when
receiver for invoke's property is flexible.
^KT-30695 Fixed
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
New resolution applicability is needed in cases when error is found,
but candidate still should be selected. Currently there are two cases,
when this behaviour is required:
- unstable smartcast (choose candidate with non-nullable parameter)
- unknown lambda parameter type (against non-functional expected type)
KT-36264
Mikhail Glukhikh