Rule java:S1905 (and probably variants in other languages) says to remove redundant casts,
The textRange dict that is returned by the web_api (e.g., issues/search) gives the range of only the type name in the cast. For instance, if the cast is (String) foo and SQ determines that foo is definitely of type String and the cast is redundant, it will return an issue with textrange.startOffset as the index of the S and textrange.endOffset as the index of the character after the g. In other words, it identifies
“String” as the problematic code.
But the cast also includes the parentheses. So really, the problematic code should be identified as “(String)”, i.e., the startOffset should point to the ( and the endOffset should point to the character after the ). That would also make it easier to automate removing these with a script, particularly when developers put arbitrary whitespace between the type and the parentheses.
I understand your parenthesis issue. I am interesting in better understanding why it is such an issue for you. Shall I guess that you are doing some automatic replacement of the issues ? If yes, a quick fix is currently proposed in SonarLint, and we could leverage it in other steps of the analyzing process. If not, would you please provide me some insights?
Thanks for your help.
Yeah, I’m looking at some kind of automated approach. And of course I could just have the script look for the parentheses, so it’s not really blocking me in any way, it was just a suggestion for improvement.
When I searched here for S1905, I found a few bug reports that mentioned cases where removing the “redundant” cast caused the compile to fail. It would be interesting to try that automatically, such as having a script surround the part marked by SQ with /* */ (assuming Java or similar) and then attempting a rebuild, then using the web_api to mark the ones that caused failure false positives.
I did something similar with rule S2111, which complains about using the BigDecimal(double) constructor due to floating point conversion errors. This isn’t really a problem for literals like 0.0, and the textRange for S2111 shows the entire constructor call, so I wrote a script to recognize those cases and demote those cases from bugs to smells.