IssueTracker

Thank you for the report. At line 183,

-keepclassmembers,allowshrinking,allowobfuscation,includecode class kotlin.jvm.internal.Intrinsics {
    void throwNpe();
}

and we don't support `includecode` modifier yet: https://r8.googlesource.com/r8/+/refs/heads/master/src/main/java/com/android/tools/r8/shaking/ProguardConfigurationParser.java#821 Changing this as a feature request.

------

From https://www.guardsquare.com/en/products/proguard/manual/usage#keepoptionmodifiers

includecode
Specifies that code attributes of the methods that the -keep option keeps should be kept as well, i.e. may not be optimized or obfuscated. This is typically useful for already optimized or obfuscated classes, to make sure that their code is not modified during optimization.

Until we support that, a workaround is obviously to not use that. :) But, may I ask why you specify that rule?

It's a rules file provided by ProGuard when you pay for support. I'm no obfuscation expert, but since it pertains to Kotlin's Intrinsics I think it's important. I had to comment the entire rule for now, please advice on the best possible solution.

Thanks

Intrinsics#throwNpe seems simple enough yet not that trivial to be optimized further, e.g., being inlined: https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/jvm/runtime/kotlin/jvm/internal/Intrinsics.java#L36 So, if you want it to belong to Intrinscis, i.e., not floating around other parts of your program, you can simply use the following rule:

-keepclasseswithmembers class kotlin.jvm.internal.Intrinsics {
  void throwNpe();
}

which will keep both Intrinsics and the member method `throwNpe` if used. (`keepclassmembers` will keep the method only if the enclosing class is kept as well.)

Note that `includecode` specifies that the code of that member may not be optimized or obfuscated, while `allowshrinking` and `allowobfuscation` specify they can be shrunk or obfuscated, which sound contradictory. I'd remove all keep option modifiers in this case.

I cannot see us honoring 'includecode'. It says in the description:

"Specifies that code attributes of the methods that the -keep option keeps should be kept as well, i.e. may not be optimized or obfuscated. This is typically useful for already optimized or obfuscated classes, to make sure that their code is not modified during optimization."

We are translating everything into an intermediate representation and will for the most part output DEX code, which is not java-byte-code. And even in the class-file backend it seems unlike we will keep the original code for now.

For class file backend, how about *not* translating java byte code into IR, i.e., keeping code attributes as-is and skipping all conversion/optimization passes, and outputting it at the end if that method is specified with `includecode`? For DEX backend, of course it is non-sense, but we can at least regard it as per-method `-dontoptimize`.

As already mentioned the use of 'includecode' cannot be honored when R8 is converting from class file to dex. When generating class file output R8 will generate valid class files. If there are situations where the generated code pattern is problematic (e.g. has a negative performance impact), then this should be solved in general in R8, and not relying on setting this modifier. Tools that need to post-process the class file output from R8 cannot rely on expected patterns from e.g. javac or kotlinc.

Fixed in https://r8-review.googlesource.com/c/r8/+/39414.