Due to updated K/JS klib ABI
Add dependency of KotlinCoverageExtension to idea test classpath because of a new check introduced in 1806.
(cherry picked from commit bffbe89f53)
Workaround for JPS build by copying compiler.xml in test runner before tests
For gradle just copy it in the processResourcesTask of idea project
#KT-34528
It was missing during configuration refinement thought new scripting API and during loading script configuration on Gradle project import
Do not pass additional classpath to configuration classpath: this may only affects Gradle with New scripting API (because it isn't used from other places)
In additional classpath kotlin-compiler and kotlin-stdlib was passed and there is no needs for this during loading Script Definitions through new scripting API
^KT-34626 Fixed
In JDK 12+ source version should be passed using --source option,
instead of -source. This commit uses correct option based on the
JDK current build is using.
Fixes KT-33050
When running KAPT incrementally, make sure to pass error/NonExistentClass.java
when there is at least one source file to process. This is to make sure
APs that must resolve all types are able to do so.
Test: updated KaptIncrementalWithAggregating/WithIsolating
It allows to fold these blocks and navigate to them in the IDEA.
Also, this commit adds compiler configuration keys to control generating comments with paths for file blocks,
and now generating such comments is enabled only in our tests.
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
Svyatoslav Kuzmich