Hello.
In Clang Tidy there is an option to apply fixes automatically if a
checker can suggest something. But I can't find similar functionality in
Clang Static Analyzer (CSA).
My check is too complex to be part of Clang Tidy but I can provide to
user an option to fix some places automatically. Is there any option to
do it with CSA?
Thank you.
Hi!
As far as I know, the analyzer currently doesn’t support FixIts in any of the output types, unfortunately. I guess it wouldn’t be too hard to add it to BugReport, and let diagnostic consumers implement it on their own.
Cheers,
Kristóf
I'm still curious though - how can a path-sensitive check suggest anything without a high risk of suggesting a breaking or incorrect change? There are just too many ways of manipulating execution paths and events on these paths and it's very hard to figure out which specific modification would be the right one.
Eg., suppose you've found a division by zero bug:
01 int foo(int x) {
02 int y = 0; // note: `y` is initialized to 0
03 return x / y; // warning: division by zero!
04 }
What would be the fixit that you'd suggest:
(a) initialize `y` with 1 instead,
(b) insert `assert(y != 0 && "Don't divide by zero!")` before the return statement*,
(c) return `y / x` instead?
I guess Kristoff's uninitialized field after construction checker is actually a good candidate for fixits: in many cases you can avoid the warning by initializing the field with {} (as long as it's your direct field and it's default-constructible). But even then, the bug may be worse than that, eg. it might have been in fact caused by invalid control flow somewhere in the constructor. Or the default constructor may be the wrong constructor to use even if available. I actually remember how in my early days i zero-initialized a field in my constructor and got 20 test failures simply because the garbage value from the stack was working much better 
It was worth it though. So, yeah, i guess it's a good example of a path-sensitive check that could occasionally take advantage of fixits. I'd love to learn about other such checks or understand what do they have in common.
At first I use path-insensitive callback - check::ASTCodeBody. What my
check will do - find possibly inefficient container usages and suggest
possibly better container for different situations. Set of supported
cases is limited (e.g. I limit this check only by function scope - a
container has to be declared in function scope, without any outer
pointers/references, etc.).
So for my quite small set I can provide FixIt functionality. But I agree
that support FixIt for changing containers can be very complicated if we
are talking about general C++ without limitations.
15.04.2019 18:37, Artem Dergachev пишет:
Hmm, at a glance this doesn't sound like a path-sensitive check. In order to decide whether you can replace the container with a different container you have to understand how the container is used on *all* execution paths, not just one path. For that purpose the technology behind the Static Analyzer wouldn't be very helpful.