This commit partially reverts 970ee4539b.
The Kotlin/Native klib compilation task configuration logic involved
adding dependencies for the compiler plugin artifacts. However, the
compiler plugins classpath, shared across all of the K/N tasks, was
tracked as the tasks' input. This made the following scenario possible:
1. Configuration of some of the Kotlin/Native tasks is avoided at the
evaluation phase;
2. During task graph construction, one of the tasks are evaluated, and
to determine their dependencies, Gradle resolves their inputs,
including the compiler plugins classpath mentioned above;
3. Another K/N task is evaluated afterwards, and the configuration logic
attempts to add a dependency into the compiler plugin classpath
configuration, which has already been resolved in (2).
The build fails.
Fix this by cancelling task configuration avoidance for the K/N tasks.
Issue #KT-36804 Fixed
values within initializer blocks.
The issue occurs in code like this:
```
class C {
var b = true
init {
b = false // Missing PUTFIELD for this statement
}
}
```
Added a new statement origin for field initialization (at declaration)
instead of relying on `origin == null` in ExpressionCodegen to determine
whether to generate the initializations.
This was unintentionally broken in
d68a1898d0.
Before this commit we had two statements blocks for 'for' loops:
range variable declaration + iterator variable declaration + while loop.
However, BE requires a bit different loop structure to make lowerings
properly so in this commit iterator declaration & while loop were
extracted to separate block.
Before this commit, all library classes were just stubs.
This commit helps to solve problems with some functions
indirectly used by BE, like IntProgression.first.
Otherwise, path will be set to the root project. Given that we provide
task names in relative form rather than absolute, that will lead to
launching this task in all subprojects (e.g. task 'jvmTest'). This might
be a huge issue, because when we create run configuration for specific
test method/class, we pass test filter as well. This test filter will
execute in all projects with matched test tasks, so if some other
subproject has similarly-named test task, but doesn't have a suitable
tests for that filter, the whole build will fail.
Note that the ideal fix would involve using fully-qualified task names:
the current approach might lead to isses in advanced scenarious (e.g.
when user selects several test files from different modules -- then, we
won't be able to find one exact project path for the whole test run)
^KT-35038 Fixed
Sergey Igushkin