Closed tyvsmith closed 3 years ago
Thanks for doing this! Can you explain a bit more about why (2) is required? What is different here that means that we need these for Kotlin but not for Java?
Thanks for doing this! Can you explain a bit more about why (2) is required? What is different here that means that we need these for Kotlin but not for Java?
Kotlin makes different use of synthetic methods than Java. In Kotlin, the use of default parameters on methods causes multiple synthetic method signatures to be generated in bytecode. This was prominent for any external class using referencing those methods via a direct reference or an override. For Java, nothing needs to change and removing this restriction would just be extra noise in the jars and default the original intention of filtering those out.
Sorry for the delay, my github notifications are not set up properly I guess :(
Thanks for the explanation, makes sense!
Thanks!
This addresses two bugs when dealing with ABI classes for Kotlin.
If you're using a mixed source set or a kt target without any kt files, the folder isn't generated to hold the abi class files. When an upstream target tries to consume this target, it fails because of a missing folder. This creates the temp folder if it's supporting source abi generation.
For Class ABIs, methods with synthetic parameters were stripped. The means that overrides become problematic across targets. This preserves more signatures in the case of Kotlin by keeping synthetic methods for Kotlin.
This has been tested and deployed on the internal Uber Buck fork.