[cfe-dev] Clang Static Analyzer Inline

[Xin Wang via cfe-dev]

Thank you very much!

You're right. The error happens because of some defects in my checker. With
the help of Gábor Horváth, I have made some changes to my checker which
will use the checkBeginFunction instead of checkPreCall to capture the
construcor.

Regards,
Xin

2017-07-07 3:14 GMT-07:00 Artem Dergachev <noqnoqneo at gmail.com>:

> There may be various reasons why the analyzer doesn't inline the function;
> this option allows inlining of allocation calls, but the function may fail
> to be inlined for a different reason. The logic is complicated and is
> mostly concentrated in ExprEngine::defaultEvalCall() and
> ExprEngine::shouldInlineCall() and a few surrounding functions. Whenever i
> badly want to know why is or isn't a certain function not inlined, i just
> sit in this code under a debugger and see why he does it.
>
> I do not remember the current status of C++ allocation functions, but it
> might be that they're explicitly disabled because of some weird false
> positives in other checkers, that we didn't have time to fix.
>
> Generally, though, you should not rely on any function being inlined when
> making a checker, because we'd never be able to inline all functions. For
> example, we may skip inlining because the function's body looks too
> complex. The checker should ideally work safely even when inlining is
> completely disabled.
>
>
> On 7/4/17 2:34 PM, Xin Wang via cfe-dev wrote:
>
>> Hello everyone!
>>
>> I am writing a checker to explore the constructor and the destructor. It
>> seems that the analyzer doesn't inline the new operator like/A *a = new
>> A();. /So I set /c++-allocator-inlining /to be true which I think will let
>> the analyzer inline the constructor, but it didn't work. Can anyone explain
>> this?
>>
>> Look forward to your help!
>>
>> Regards,
>> Xin
>>
>>
>> _______________________________________________
>> 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/20170707/1bad73f4/attachment.html>