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)
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?