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

[Artem Dergachev via cfe-dev]

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.

On 4/15/19 11:01 AM, Alexander Zaitsev wrote:
> 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