[cfe-dev] clang-tidy and static analysis for exception safety

Martin Böhme via cfe-dev cfe-dev at lists.llvm.org
Fri Mar 17 03:11:00 PDT 2017


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/20170317/86b24029/attachment.html>


More information about the cfe-dev mailing list