-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go: Fix FPs in go/incorrect-integer-conversion
query
#16234
Go: Fix FPs in go/incorrect-integer-conversion
query
#16234
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks plausible, though of course a performance risk. Sounds like you already have data on this from QA though?
@smowton I only did MRVA. I will do a QA run. |
It was introduced in github/codeql-go#718 in response to github/codeql-go#717, to check that we don't have type assertions as sinks. We now have other tests covering type assertions.
99c7b97
to
212a0f2
Compare
I did a DCA run. No alert changes. The two biggest repos had a slight increase in analysis time, of 2-3%, but almost all the rest showed no difference at all. I suspect this may be due to the field flow branch limit. I will do a QA run just to be sure. |
QA results look fine. No increases in alerts - not sure why that's different from MRVA. Big decreases on a couple of repos, just for |
I found the type switch FPs while looking at the results for #16120, which fixed some broken flow into type switch clauses. While thinking about how best to fix them I also realised that any type assertion should transform the flow state, so I implemented that as well.
A before and after MRVA run suggests that on the top 1000 repos this PR removes 218 FPs, but the more detailed picture is more nuanced. On a very small number of repos it increased the number of alerts. This seems counter-intuitive, as this PR only adds barriers and hence should only remove results. I investigated and found that this was because removing some flow allowed us to find more results within the default limit for
fieldFlowBranchLimit
.