[cfe-dev] clang-tidy and static analysis for exception safety
Jonas Toth via cfe-dev
cfe-dev at lists.llvm.org
Sat Mar 18 09:11:33 PDT 2017
I will try to work on a prototype for the clear cases, so we will find
out where problems are.
The review with the remarks from aaron is here
https://reviews.llvm.org/D30746
One more thing that came me to mind: Defaulted operations have the
noexcept specification from the compiler to they? If yes, there should
already exist some logic for marking functions/operations noexcept.
I think that check should be incremental anyway, so the absolute clear
cases will be done first. If that works out, more can be added in my
opinion.
Greets :)
Am Fr, 17. Mär, 2017 um 11:11 schrieb Martin Böhme
<mboehme at google.com>:
> Sorry for the late reply.
>
> If you want to see an example of flow-sensitive analysis in
> clang-tidy, take a look at UseAfterMoveCheck.cpp.
>
> That said, I also don't see yet why a lexical analysis isn't
> sufficient (i.e. check whether the throw is lexically contained
> within the catch, with special handling at the boundaries of lambdas)
> -- though I'm sure I'm just missing something. Can you provide a link
> to Aaron's review?
>
> This article has a good overview of some of the intricacies of
> noexcept:
>
> https://akrzemi1.wordpress.com/2011/06/10/using-noexcept/
>
> In particular, it has some good examples of functions that can be
> marked noexcept, even though they call non-noexcept functions, and
> vice versa (think of a function whose implementation happens not to
> throw today but which doesn't want to make that guarantee in its
> contract). So you'll need some way of marking false positives and
> false negatives as intentional.
>
> An additional wrinkle is when the argument to noexcept depends on a
> template argument -- you may want to initially just ignore these
> cases.
>
>
> On 17 March 2017 at 10:17, Manuel Klimek <klimek at google.com> wrote:
>> On Thu, Mar 16, 2017 at 7:06 PM Devin Coughlin <dcoughlin at apple.com>
>> wrote:
>>>> On Mar 16, 2017, at 4:42 AM, Manuel Klimek via cfe-dev
>>>> <cfe-dev at lists.llvm.org> wrote:
>>>>
>>>> Yea, none of these seem to be path sensitive, but only flow
>>>> sensitive, which clang-tidy supports.
>>>
>>> I’m surprised that even flow sensitivity is needed. I would have
>>> thought a purely lexical analysis on the AST would be sufficient.
>>> What is the case where the analysis would need to compute
>>> per-program-point facts?
>>
>> Well, will depend on whether you'll count analyzing where the
>> "throw" and the corresponding "catch" is as flow sensitive (I would,
>> but I'm no expert :)
>>
>>>
>>> I could see context sensitivity being useful (to look through calls
>>> to unannotated functions) — but with the exception of function
>>> pointers and virtual calls I would expect calls to be better
>>> handled by analyzing the call graph from the bottom up, inferring
>>> the exception behavior for callees before analyzing the caller.
>>>
>>> Devin
>>>
>>>
>>>>
>>>>
>>>> On Thu, Mar 16, 2017 at 12:37 PM Jonas Toth via cfe-dev
>>>> <cfe-dev at lists.llvm.org> wrote:
>>>>> Why would the second case not be possible?
>>>>> What i have in mind by example:
>>>>>
>>>>> ```
>>>>> void definitly_throws() { // should be marked noexcept(false),
>>>>> maybe as configuration option
>>>>> if (some_condition())
>>>>> throw std::logic_error{"Reasons"};
>>>>> else
>>>>> // do unproblematic stuff
>>>>> }
>>>>>
>>>>> void probably_throws() { // this needs more analysis then AST
>>>>> matching so leave it as is
>>>>> try {
>>>>> // operation
>>>>> if (op_failed())
>>>>> throw std::runtime_error{"Operation failed"};
>>>>> }
>>>>> catch (std::runtime_error& e)
>>>>> { /* handle */ }
>>>>> }
>>>>> ```
>>>>>
>>>>> The second one can be noexcept if the operation will not throw.
>>>>> It is not noexcept if operation is not noexcept.
>>>>> What did I miss?
>>>>>
>>>>> The deeper analysis will not happen if the analyser does not see
>>>>> all code, but if it can shouldnt there the possibility to decide?
>>>>> Maybe it has bad complexity and is therefor not practical. But
>>>>> maybe in some cases there can be insight gained?
>>>>>
>>>>> Am Do, 16. Mär, 2017 um 11:25 schrieb Daniel Marjamäki
>>>>> <Daniel.Marjamaki at evidente.se>:
>>>>>> As far as I see:
>>>>>>
>>>>>>
>>>>>>
>>>>>> - a function calling only `noexcept` operations that does not
>>>>>> throw can be marked noexcept
>>>>>>
>>>>>>
>>>>>>
>>>>>> possible
>>>>>>
>>>>>>
>>>>>>
>>>>>> - a function that has a `throw` statement not within a
>>>>>> `try/catch` block can be marked noexcept(false)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Not possible
>>>>>>
>>>>>>
>>>>>>
>>>>>> - a function calling a function that is not marked noexcept can
>>>>>> not be marked noexcept
>>>>>>
>>>>>> but it could be noexecpt with deeper analysis on what
>>>>>> exception could be thrown and what exceptions are handled
>>>>>>
>>>>>>
>>>>>>
>>>>>> not possible
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cfe-dev mailing list
>>>>> cfe-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> --
> Martin Böhme
> Software Engineer
> mboehme at google.com
>
> Google Germany GmbH
> Erika-Mann-Straße 33
> 80363 München
>
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
>
> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat
> sind, leiten Sie diese bitte nicht weiter, informieren Sie den
> Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
>
> This e-mail is confidential. If you are not the right addressee
> please do not forward it, please inform the sender, and please erase
> this e-mail including any attachments. Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170318/c2e9f088/attachment.html>
More information about the cfe-dev
mailing list