Open rieske opened 3 years ago
Instead of doing our own Kotlin compilation avoidance we should reuse what the Kotlin team has done since then https://youtrack.jetbrains.com/issue/KT-57565
An internal prototype of the required API is scheduled for Kotlin 1.9.20 and for public consumption in Kotlin 2.0.
1.9.20-Beta includes the internal prototype, see the KT issue linked above for details
We identified two issues with the current implementation, preventing adopting the new API:
This is blocked on https://youtrack.jetbrains.com/issue/KT-62555 which is now scheduled for Kotlin 2.1.0-Beta1, that's mid-September with the GA late November.
The current implementation of Kotlin build script compilation avoidance has a limitation where it does not work with inline functions. When an inline function is detected, the ABI extractor used in compilation avoidance gives up and the jar where this occurred will no longer participate in compilation avoidance - any change in it will cause the build scripts to be recompiled.
The reason for this limitation is our inability to determine whether some compiled inner class is part of an inline function and whether it should be part of the ABI (and thus a change to it should require recompilation). This test demonstrates the current case that we are not able to detect when naively treating the body of an inline class as ABI. The lambda declared within an inline function is compiled as a separate class and when visiting that class for ABI computation, we can not tell whether it originates in a public inline function.
Kotlin 1.5.30 may add a flag in
kotlin.Metadata
that would allow us to identify whether a class is part of an inline function (and thus a part of the ABI). With this, we should be able to fully treat the inline functions as ABI and allow build logic that uses inline functions to participate in build script compilation avoidance.