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.
Can you provide a minimal reproducer with a text-based snippet of code (better yet, a zipped-up mini project)? We really canāt (wonāt) debug much based on screenshots.
Since 2.2 release a few days ago and we havenāt yet a released the updated version of the analyzer, it could happen that the problem is related to the fact that weāre still using previous compiler and Analysis API.
Once we release the new analyzer with the latest compiler version, we can check if the issue is gone.
However, the 10.8 version is quite old, the latest versions of SQ contain full migration to K2 and the next one will potentially contain a 2.2 version support.
Itās hard to understand which exactly changes in the compiler caused the issue, however Iād suggest you first upgrade to the latest SQS version or wait for the one with the official Kotlin 2.2 support. If the issue remains, then we will be able to investigate and understand what happens.
).
