Use lazy properties to configure KAPT tasks and in the model builder.
Also, avoid eager dependency resolution of the kaptExternalClasspath
file collection.
Avoid storing references to KotlinCompile task and use lazy properties
to configure task. Values are kept in-sync with the
Kotlin compile task (for the stub generation) using this mechanism.
This change migrates to using properties of KGP tasks and Gradle
built-in tasks. Also, in TaskProvider class, Configurator instances are
created to configure KGP tasks.
Update AbstractKotlinCompile, KotlinCompile, and Kotlin2JsCompile to
use Gradle properties, and introduce Configurator classes that are
using configuration-time data to configure task. Also, introduce
TaskConfigurator interface that should be implemented by classes that
are used to configure tasks.
When getting the incremental compilation information use the
task graph which processes all tasks present in it. Tasks have
all information that is needed to get IncrementalModuleInfo for all
compilations.
collectPotentiallyCapturedTypeParameters no longer stops on the first
class when going through parents. This is needed because otherwise type
parameters of the containing class, and its outer classes, were never
considered "captured", and thus not duplicated/remapped later in
LocalDeclarationsLowering.
This led to the IR where a local function referenced generic type
parameters of the outer class. On JVM, local function is generated into
a private static function in that container class, and static functions
can't use generic type parameters, which crashed some bytecode
processing tools.
Also, add another explicit call to `seeType` to cover references to
generic type parameters in function return types.
#KT-45941 Fixed
It seems logical to do, because KtFunctionLiteral is KtDeclaration
and KtLambdaExpression is not. Also FirAnonymousFunction use it as
realPsi reference
For code such as:
```
try {
var y = "y"
for (i in 0 until 1) {
return y
}
} finally {
println("finally")
}
```
The local variables `y` and `i` ended up covering the finally block as
well in the debugger.
This change splits the range of the locals so that they do
not cover the finally block.
This change does not change the inliner to do similar transformations,
so the range of locals is still wrong win finally blocks when inlined
into an inline function. Added a failing test to that effect.
Ivan Gavrilovic