BuildOutputCleanupRegistry tracks the all of the outputs that belong to
the Gradle build, so when Gradle runs in an unknown state (e.g. without
any history), it can detect stale outputs in the output directories and
delete them.
Since this is an internal API, its usage is removed. Instead, another
way to tell Gradle that a set of directories belongs to the build is to
add them to the `delete` task targets.
Remove the implementation of the `FileCollectionInternal` interface in
`KotlinCompilationOutput`. This interface may change unexpectedly (and
does between Gradle 4.10 and 5.0) so we need to get rid of its
implementation.
On the other hand, we can't just implement `FileCollection` instead
because Gradle internally assumes that all `FileCollection` instances
are also `FileCollectionInternal`. So the way to fix this is to remove
`SourceSetOutput` from superinterfaces of `KotlinCompilationOutput`
altogether.
Instead, to work with `SourceSetOutput` and `KotlinCompilationOutput`
in a uniform way, provide a wrapper for `SourceSetOutput`:
`KotlinWithJavaCompilationOutput` that is basically a proxy
class.
Workaround for IDEA-200192
IDEA patches JavaExec tasks and adds
agentlib:jdwp= jvm parameter when running under debug.
Replace parameters after IDEA has finished patching parameters.
This change reverts the AssignmentTranslator logic to a previous state
of "if we assign to a val, tranlate to backing field". Previously a
check whether or not we are inside of a constructor was added. The
check didn't detect secondary constructors, hence initializing of
val's with backing field started to work incorrectly.
The check itself was added in an attempt to prevent augmented assignment
operators to reference the backing field. The check seems to have been
wrong, because an augmented assignment could happen inside a construcotr.
A more correct fix was added later. It seems that it is safe now to
revert the logic back and rely on the frontend to only allow assignment
to a val property during initilization.
Shared instance is incorrect here and causes clashes when many
definitions are loaded in the same process.
Also make the diagnostics in case of clashes more verbose.
There is a trade-off between robustness of check and accuracy of the
diagnostic: the previous version, which works on generation, was too
fragile and lead to false-positives. Now we check on state machine
generation. However, since we do not have PSI for call, we can only
report diagnostic on whole suspend function or suspend lambda.
Additionally, the state machine is generated on crossinline suspend
lambdas regeneration and thus we do not have the PSI for the lambda as
well!
#KT-27130 Fixed
#KT-27258 Open
Ilya Gorbunov