A high interest topic for me is code coverage supp...

# kotlin-native

[pajatopmr]

A high interest topic for me is code coverage support for Kotlin multiplatform, especially native targets. Understandably, there is a dearth of information about JB roadmap plans for native code coverage tools. If I have this wrong I would love to hear it. So that leaves me with standalone solutions for now, like gcov and related tools, of which I know next to nothing having been focused on JVM since ’95. While I did do C and C++ for a number of years, code coverage did not cross my radar until a few years ago and since then it has been all Jacoco which has it’s own set of issues for Kotlin/JVM. So I’m looking for guidance on how to leverage available code coverage tools with the Kotlin/Native compiler. For example, am I limited to tools that support LLVM? Is there a way to hook into GCC/gcov? Feel free to respond in #code-coverage or a thread here.

[pajatopmr]

And it would be good if Gradle has a big role in this piece of work.

[pajatopmr]

So I found this page: https://clang.llvm.org/docs/SourceBasedCodeCoverage.html which seems to say there are three ways to do code coverage with a LLVM compiler: 1) (recommended) source based, 2) a sanitizer (I have no clue what a sanitizer is) and 3) gcov using debug info, a gcc based approach.

[pajatopmr]

1) looks interesting if your LLVM compiler supports both the “-fprofile-instr-generate” and “-fcoverage-mapping” switches which kotlinc-native does not support according to the -help and -X command line arguments.

[pajatopmr]

2) might be interesting but I’m guessing not. It would be good to know if this is a bad guess.

[pajatopmr]

So 3) looks like the most promising path for now, if only because kotlinc-native supports a “-g” switch.

[pajatopmr]

I tried 3) using the hello.kt native sample code and get:

bash-3.2$ gcov -a hello.kt
hello.gcno: No such file or directory

[pajatopmr]

And looking at the gcov man pages (for gcc) it would appear that the compiler must support a couple of command line switches like the pair mentioned above in the discussion on 1).

[pajatopmr]

So my next thought is to attempt to leverage the -Xprint-locations compiler switch and use the output to cobble together a new tool, Kococo that is source based rather than IR based. I so want to hear from JetBrains or anyone for that matter on the pros and cons of this approach. It’s being a lot of work is totally understood. I wonder if this switch is available for the JVM and JS targets? @olonho?

[olonho]

we will evaluate possibility of providing code coverage information by adding compiler switch taking care of all defails

[pajatopmr]

Awesome! Thank you.

[pajatopmr]

@olonho assuming your evaluation yields a positive result, I will gladly volunteer to test or assist in developing whatever needs to be done to make code coverage a first class citizen in Kotlin compilers. Please keep me apprised if you would.