Vararg parameter in reflection type is interpreted as covariant
array type against array in expected functional type and as
vararg element type otherwise. For instance having function
fun foo(vararg args: Int): Unit { /*...*/ }
reference ::foo can be passed against expected
(Int) -> Unit,
(Int, Int) -> Unit, etc.
In none of such cases type for parameter in foo's reflection type
should be changed to array.
However, against expected type (IntArray) -> Unit args' type
must become IntArray.
^KT-25514 Fixed
In COMPOSITE analysis we don't have a constant SDK dependency for whole
ResolutionFacade, so we have to find it manually via calling
'findSdkAcrossDependencies'
In SEPARATE mode we do have such a constant SDK dependency, but there
was an assumption that it doesn't make a difference (i.e.
findSdkAcrossDependencies always return the same SDK as passed constant
one)
Turns out that assumption was wrong, particularly for projects with
duplicate SDK entries in project structure. Then we would choose one SDK
in some cases, and the other one on other cases - even though they a
bit-to-bit equal, we will create separate descriptors for them, which
might lead to some issues, like in KT-34802
^KT-34802 Fixed
* Extract replacement of IrGetField/IrSetField into a separate
file-level lowering (should reduce the amount of work to linear in
the number of classes rather than potentially quadratic)
* Extract static backing field construction into JvmDeclarationFactory
and move that lowering after PropertiesToFields lowering to reduce
code duplication
Check worked incorrectly in case when argument type and expected type are the
same intersection type, which is possible for local variables without explicit
type declaration.
For some reason, working without APT requires this call in JavacWrapper.
From the other hand, working without APT does not require
Kotlin class files to be in javac classpath.
Imports resolution is a rather time consuming task and doesn't have
`checkCanceled` on its computation path. So, if a thread is resolving
imports it will do it until the end of computation, which can lead to
unnecessary work and some IDE freezes.
#KT-34990 Fixed
This is a refactoring to simplify the API of
ExternalDependenciesGenerator and to constrain future additions of
platform-specific stub generator extensions.
* When referencing the companion itself, they should use the $$INSTANCE
field, not the (null until <clinit> returns) Companion field of the
interface.
* Interface companion init blocks should be made static.
Fun fact: this is not actually validated when loading the class; and
even when compiling a java file against a class file that does this,
only javac 9 has a check (1.8 and before simply crashes with
NullPointerException somewhere deep inside the compiler).
Zalim Bashorov