This commit in fact changes two very related places:
- first, it implements forgotten 'enhancedForWarnings' in K2 enhancement
- second, it repeats KT-48515 fix for K2 while enhancing wildcards
#KT-65594 Fixed
Related to KT-48515, KT-63746
There is a thing that `CandidateCollector` adds error candidate to the
list of resulting candidates only if its applicability at least the
same as current applicability of the collector
Also there is a problem, that deserialized symbol provider in CLI compiler
and stub-based symbol provider in AA may return the same declarations
in different order. This provokes the difference in the resulting set
of candidates between the two modes:
```
val x by unresolved
```
During the resolution of this code compiler tries to find function `getValue`,
and there are 6 of them in the stdlib. From them we are interseted in
specific three:
1. `fun <K, V> Map<K, V>.getValue(key: R|K|): R|V|`
2. `inline operator fun <V, V1 : V> Map<in String, @Exact V>.getValue(thisRef: Any?, property: KProperty<*>): V1`
3. `inline operator fun <V, V1 : V> MutableMap<in String, out @Exact V>.getValue(thisRef: Any?, property: KProperty<*>): V1`
- (1) is inapplicable with `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
- (2) and (3) are inapplicable with `INAPPLICABLE_WRONG_RECEIVER`
- `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR` is more specific applicability than `INAPPLICABLE_WRONG_RECEIVER`
- CLI compiler always sees those functions in order 1 -> 2 -> 3
- AA providers sometimes returns them in order 2 -> 3 -> 1
So in CLI compilation candidates (2) and (3) are not added to the resulting
set, as they are "less applicable" than (1), but in AA compilation they
can be added to the set before (1), which causes sporadic change in
FIR dump of `unsafeAssignmentExtra.kt`
To workaround this problem it was decided to treat `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
and `INAPPLICABLE_WRONG_RECEIVER` applicabilities as "equally specific"
^KT-65218 Fixed
`StubBasedFirTypeDeserializer` handles function parameter with a
receiver with a special exception, which sets it as
`ExtensionFunctionType`, but skips setting special function kinds for it
even when the function parameter type is a special function kind. This
drops `Composable` annotation from a lambda expression if the function
parameter taking the lambda expression as an argument has a receiver,
which causes a severe CodeGen error for Compose app on K2 Android
Studio.
^KT-66526 Fixed
It is now unneeded, and future needs should be possible to
be resolved otherwise.
Removing it will simplify further changes to tree generator,
especially for IR.
Stanislav Ruban