Kotlinx Serialization annotation line included in the coverage report

[saurabh-somani-philips]

Describe the bug
Recently, I updated the Kover version in my KMM project from 0.8.1 to 0.8.3, and I noticed my data classes annotated with @Serializable were not fully covered. The annotation line looks yellow in the HTML report, stating it is partially covered.

I've tried excluding "*.*serializer*" from coverage report (as mentioned in some previous issue reported 1 or 2 years ago), but it didn't help.

Errors
N/A

Expected behavior
Data class should be fully covered, ignoring the @Serializable annotation line. I don't want to exclude the whole data class to solve this issue, just the annotation part. Am I doing something wrong or Kover needs to consider updating itself after Kotlin 2.0 update (I'm using v2.0.20)?

Reproducer
N/A

Reports
This is my data class in the Kover report:

This is the coverage summary:

Environment

• Kover Gradle Plugin version: 0.8.3
• Gradle version: 8.7
• Kotlin project type: Kotlin/Multiplatform
• Coverage Toolset (if customized in build script): Kover
• Other context important for this bug: Kotlin version - 2.0.20

[shanshin]

Hi,
do you have the option to exclude companions ("*\$Companion") for serializable classes from the report?
If so, does it fix your issue?

[saurabh-somani-philips]

@shanshin
I tried excluding it from the coverage report. The Companion object's coverage disappears, but main data class's 'Branch' and 'Instruction' coverage still has some coverage left. The same is reflected in our SonarQube report, so the ultimate aim is to fix the Sonar report coverage.

[johngray1965]

Similiar issue with android's @parcelize

[mgroth0]

Confirming I have this issue too with @Serializable

[kszorin]

@shanshin , we have this problem too! This is very disturbing.
We left with Jacoco to Kotlin, because it has the same problem, but Kover also had the same problem after Kotlin update to 2.0

When is it planned to be fixed?

[JKuliska-pcty]

@shanshin we're facing this issue too and as we heavily use @Parcelable it's skewing the coverage result not in our favor.
Is there an estimate when this could be fixed?

Thank you so much.

[shanshin]

@JKuliska-pcty, we are gradually switching to using the JaCoCo agent (#720), and as a result, our reports will be rewritten. At the same time, we will try to take into account the problems with synthetic, but not marked as synthetic methods.

We try to fix the existing report for @Serializable, but fixes for @Parcelable are not in the short-term plans.

[JKuliska-pcty]

@JKuliska-pcty, we are gradually switching to using the JaCoCo agent (#720), and as a result, our reports will be rewritten. At the same time, we will try to take into account the problems with synthetic, but not marked as synthetic methods.

We try to fix the existing report for @Serializable, but fixes for @Parcelable are not in the short-term plans.

Thank you for your answer. It's a pity that the @Parcelable is not on the near timeline. Do you have some recommendations on how to globally ignore that? Is that possible with some exclusion rule? I tried but couldn't find a way.

The only thing I managed was to write a test that makes the Parcelable interface part covered by wrapping and unwrapping the class as a Parcelable but that is firstly not testing the implementation of our code but of a 3rd party dependency and also the annotation I couldn't get marked as green (tested)

cc: @shanshin

[shanshin]

@JKuliska-pcty, I will study this issue next week to see if it is possible to exclude synthetic @Parcelable declarations using filters.