zaks.anna added a comment.
>> Actually, I always test first on real code, and it seemed to be inlined. But
>> now, even if I
>> removed the pragma it was not inlined.
Looks like this patch is interfering with this inlining suppression. We had
many false positives without it. Mainly, the analyzer would not understand the
invariants of the container data structures.
`ExprEngine::defaultEvalCall` calls `mayInlineCallKind `which contains this:
`// Conditionally control the inlining of methods on objects that look
// like C++ containers.
if (!Opts.mayInlineCXXContainerMethods())
if (!Ctx.getSourceManager().isInMainFile(FD->getLocation()))
if (isContainerMethod(Ctx, FD))
return false;`
================
Comment at: test/Analysis/iterator-past-end.cpp:3
+
+template <typename T, typename Ptr, typename Ref> struct __iterator {
+ typedef __iterator<T, T *, T &> iterator;
----------------
NoQ wrote:
> We should probably separate this into an #include-able header in
> `test/Analysis/Inputs/`.
>
> Also, there's always a bit of concern that it wasn't copy-pasted from a
> standard library implementation with an incompatible license such as (L)GPL.
> Which often happens when you do your best to emulate the normal way of
> defining things as closely as possible.
We often do forward declare in the implementation file as it is done here. We
mainly use the Inputs directory to simulate system headers.
https://reviews.llvm.org/D25660
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
