It seems the original function type gets lost during resolution. Hence
thie change added a custom attribute to recover the original function
type on an anonymous function
Consider the code below
```
fun test() {
a@ b@ {
{}
}
}
```
Currently when the code is converted to FIR, label `b` is bound to the
outer lambda and `a` gets bound to the inner lambda because it's not
consumed. This is wrong and also leads transfromation to fail with
exceptions because of the unexpected consumption of `a`.
This change fixes the above issue by designating a specific node in the
AST as the allowed user of a label when the label is added.
The constraint depends on a resolution candidate, because it can be Java static or companion object's member (don't need add constraint in this case)
^KT-41978 Fixed
Assuming Java class `Super` has a protected `getName` method and a
public `setName` method.
Then, in a subclass of `Super`, FE1.0 allows calls to `setName` via the
property syntax if the property is protected and invisible due to
dispatch receiver is not `this` or `super`.
Consider the following code:
```
fun test(a: List<String>) {
a.first()
}
```
The dispatch receiver type of `first` in this case is `List<T>` before
this change. After this change, it's `List<String>`.
In addition, this change also replace the dispatch receiver type with
the more specific type if available. For example, consider the following
```
class MyList: ArrayList<String>()
fun test(a: MyList) {
a.get(0)
}
```
The dispatch receiver type of `get` is `MyList`, instead of
`ArrayList<String>`. That is, a fake override is created in this case.
Also change
org.jetbrains.kotlin.fir.types.TypeUtilsKt#hideLocalTypeIfNeeded to skip
approximating anonymous objects if there are multiple super type refs so
that resolution behaves the same (for uncompilable code).
Note that this change does not implement check for
ApproximateAnonymousReturnTypesInPrivateInlineFunctions as the check is
already turned on in 1.5 and will likely not needed when FIR becomes
stable.
ProhibitAssigningSingleElementsToVarargsInNamedForm is enabled from 1.3
so there is no need to make FIR accepting single element passed through
named arguments.
In addition, we may want to report only
ASSIGNING_SINGLE_ELEMENT_TO_VARARG_IN_NAMED_FORM_FUNCTION and not arg
type mismatch. But FE1.0 is reporting both so I am following it. If we
want to remove the redundant report, we will probably want to remove
FirNamedVarargChecker and report during resolution as a cone diagnostic.
Ivan Kochurkin