Roughly 30% of the smells being detected are something like this, which translates to hundreds of false positives. 1 - 10 line functions that trivially mutate their calling objects. In this specific case, vehicle_id_ is a private non-const member of the class, nothing fancy. The other 70% of the smells appear to correctly identify potentially const functions.
Is there some kind of misunderstanding of the rule being applied, or some scanning configuration that I should check on to get useful results out of this rule?
SonarQube Enterprise Edition Version 8.9.8 (build 54436)
We released two patch releases for the LTS since 8.9.8. Could you upgrade to at least 8.9.10 so we can rule out issues that were already solved? Thanks.
If the issue persists after upgrading, could you look at the analysis log? I suspect some parsing errors impact the analysis quality. See, for example, here for some tips: https://rules.sonarsource.com/cpp/RSPEC-2260.
Just finished upgrading and re-ran the analysis, it came back with the exact same amount of issues. My next step was going to be to check the logs and I see five log files being generated: access.log, ce.log, es.log, sonar.log, and web.log. Could you clarify which of these logs would have the analysis logs and give me a hit what I should be looking for?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.