Unexpected arguments due to sonar pointing to the wrong module (python:S930)

[Cwanyo]

I have monorepo setup where each module might have the duplicate file name + function name but different in arguments.

> sample code here

It seems like sonar have a problem pointing to a correct module and report the issues as ‘unexpected arguments’ (python: S930) due to the function receives different arguments.
> issue on sonarcloud

I tried to define the modules in .sonarcloud.properties as below, But it doesn’t seem to be working.

sonar.modules=module-a,module-b
module-a.sonar.projectName=module-a
module-a.sonar.sources=module-a/
module-b.sonar.projectName=module-b
module-b.sonar.sources=module-b/

Any help would be appreciated.

Thank you.

[Guillaume_Dequenne]

Hello @Cwanyo

First of all, welcome to this community and many thanks to you for the clear reproducer.

This feedback is coming at quite an appropriate time, as we are about to start some work on improving symbol resolution for Python analysis.

First, to address your issue, I believe what you want to do is to set up a monorepo in SonarCloud.

Your reproducer is currently analyzed with automatic analysis and is seen by SonarCloud as a single project, which is probably not what you want when working with monorepos.

Instead, you can set up multiple projects that are analyzed separately. For that, unfortunately automatic analysis is not available.

Here is some documentation about how to set up a monorepo:
https://sonarcloud.io/documentation/analysis/setup-monorepo/
https://blog.sonarsource.com/mono-repository-support-for-github-and-azure-devops

Also, here is an example setup based on your reproducer:

guillaume-dequenne-sonarsource/py-sonar

The analysis is triggered by a Github Action (as automatic analysis is not available for monorepos - feel free to replace this with your preferred CI-based analysis configuration) and there are 2 sub-projects that are analyzed separately, each with their own sonar-project.properties. Also, .sonarcloud.properties is no longer needed.

There, we can see that the false positive is gone. I also introduced actual bugs in both projects which are correctly detected:

https://sonarcloud.io/project/issues?id=guillaume-dequenne-sonarsource_py-sonar_1&open=AXkiy0lFrLqyxp--grJZ&resolved=false&types=BUG
https://sonarcloud.io/project/issues?id=guillaume-dequenne-sonarsource_py-sonar_2&open=AXki017xvbT53MIh7Wo7&resolved=false&types=BUG

That being said, your reproducer still highlights a bug in the way our analyzer resolves symbols, as the same pattern could happen in a regular project.

Mostly, this is due to the fact that our analyzer doesn’t compute the correct fully qualified names for modules if no __init__.py is present in the package. In turn, this bug hid another bug which prevents our analyzer from correctly resolving imported symbols in some cases.

For that, I have created the following tickets: SONARPY-844 and SONARPY-846 which we will hopefully tackle soon.

Thanks again for your feedback,

Hope that helps,
Guillaume