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

Manuel Klimek via cfe-dev cfe-dev at lists.llvm.org
Fri Mar 17 02:17:50 PDT 2017


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170317/9c602330/attachment.html>


More information about the cfe-dev mailing list