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).
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.
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!
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.