[cfe-dev] [analyzer] Applying fixes automatically in CSA as it done in Clang Tidy

[Alexander Zaitsev via cfe-dev]

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 пишет:
> 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.
>
> _____
> * Bonus points for providing a similar fixit hint for:
>   02   int y = -1;
>   03   return x / (++y)".
>
>
> On 4/15/19 7:55 AM, Kristóf Umann via cfe-dev wrote:
>> 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
>>
>> On Sun, 14 Apr 2019 at 16:40, Alexander Zaitsev via cfe-dev
>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>     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.
>>
>>     --     Best regards,
>>     Alexander Zaitsev
>>
>>
>>     _______________________________________________
>>     cfe-dev mailing list
>>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-- 
Best regards,
Alexander Zaitsev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190415/d305f7ce/attachment.sig>