Kotlin S6314 false-positive for nested map operator

[G00fY2 (Thomas Wirth)]

We recently see multiple false-positive warnings caused by the new kotlin:S6314 rule.

The false-positive happens for map (from Kotlin collections) operators inside map (from Coroutines flow). E.g.:

private fun falsePositive(): Flow<List<String>> {
    return flowOf(listOf(1, 2, 3)).map { list -> list.map { it.toString() } }
}

The second map operator is marked as noncompliant.

We use SonarQube 9.9 (build 65466) along with Gradle plugin 4.3.0.3225 in an Android Gradle project with Kotlin 1.9.0 and Coroutines 1.7.3.

[jbeleites (Johann Beleites)]

Hello Thomas,

Thanks for the report.

I’ve been trying to reproduce it − unfortunately, I have not yet been able to using the provided example.

You write that the second map operator is marked as noncompliant. You mean the one called on the list, so in list.map { it.toString() }?

If this is the case, it would be indeed surprising for S6314 to raise an issue, this rule is only concerned with flows in the context of coroutines, so shouldn’t be triggering on sequences.

One potential explanation for odd behavior may be incomplete or incorrect semantic information during the analysis. That sort of problem is difficult to troubleshoot, however, as it depends greatly on the configuration of the project and analysis.

Would it be possible to create a small project containing a minimal reproducer, which includes the build configuration and source file to reproduce this issue? You can either share the project with a GitHub (or similar) link or post the complete Gradle build file + source file here. Please also share the command you are using to analyze the reproducer project and trigger the FP (obviously all excluding any authentication tokens for e.g. SonarQube).

[G00fY2 (Thomas Wirth)]

Hi @jbeleites,

thanks for your answer. I was hoping that my short example function would maybe hint you in the right direction (but I was already afraid that its not that easy ).

Here is a short screenshot form one of the actual false-positives in our project.

Maybe I find some time to set up a minimal reproducer project, since I can not share the project with you directly.

But for your information we use a basic setup in our multi-module project along with the Gradle plugin. For analysis we simple call the sonar gradle task.

Also interesting is, that the SonarLint IntelliJ plugin does not highlight these code parts. But it does if I e.g. add the Noncompliant Code Example from the docs into some class in our project.

[jbeleites (Johann Beleites)]

Indeed, the issue shown on the screenshot looks incorrect. SonarLint not raising it makes the situation even more interesting.

For reference, I’ve tried using the example in the screenshot and reducing it such that I can compile it without access to the rest of the project:

    fun getListFlow(): Flow<List<String>> {
        return flowOf(listOf(1, 2, 3)).map { list -> list.map { it.toString() } }
    }

Unfortunately, this did not reproduce the issue for me. Once you are able to create a minimal reproducer, don’t hesitate to get back to us, even if it takes some time!

[Robert_Turner]

I’m seeing this issue as well. I’ve got 5 occurrences at the moment – all slightly different. Some are map within map, some are map within combine. One is a map within a map, within a combine. As with the OP, not easy to extract a minimal example without lots of effort.

Here’s one of the simpler ones:

userPreferences is a Flow<UserPreference>, UserPreference is a data class with just “primitives” in it. getUploadingClaims() returns Flow<List<UploadEntry>>, and UploadEntry is again a data class with “primitives” and at one enumeration.