This change was initially proposed as a solution to the problem highlighted by check-in r164677, i.e. that -verify will not cause a test-case failure where the compile command does not actually reference the file.
Patch reviewed by David Blaikie.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166281 91177308-0d34-0410-b5e6-96231b3b80d8
headers and modules in more detail. I'd still like to expand on some
of the modules-related issues further, but this is a decent start.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163989 91177308-0d34-0410-b5e6-96231b3b80d8
This allows linking to LibASTMatchersRefernce.html#<matcher><N>Anchor to
link to the N'the declaration of a matcher and automatically expand
its documentation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163386 91177308-0d34-0410-b5e6-96231b3b80d8
More generally, this adds a new configuration option 'c++-inlining', which
controls which C++ member functions can be considered for inlining. This
uses the new -analyzer-config table, so the cc1 arguments will look like this:
... -analyzer-config c++-inlining=[none|methods|constructors|destructors]
Note that each mode implies that all the previous member function kinds
will be inlined as well; it doesn't make sense to inline destructors
without inlining constructors, for example.
The default mode is 'methods'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163004 91177308-0d34-0410-b5e6-96231b3b80d8
There are two tests regressions that come from the fact that the Retain
Count checker does not cancel out inlining of ObjC methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162950 91177308-0d34-0410-b5e6-96231b3b80d8
parse doxygen comments for macros with libclang.
I'm not entirely happy about this script, but as it saves
a lot of work in keeping the docs up to date with the
actual code I think checking it in makes sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162690 91177308-0d34-0410-b5e6-96231b3b80d8
Because the CXXNewExpr appears after the CXXConstructExpr in the CFG, we don't
actually have the correct region to construct into at the time we decide
whether or not to inline. The long-term fix (discussed in PR12014) might be to
introduce a new CFG node (CFGAllocator) that appears before the constructor.
Tracking the short-term fix in <rdar://problem/12180598>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162689 91177308-0d34-0410-b5e6-96231b3b80d8
Since DynamicTypeInfo is not inherently related to inlining or to dynamic
calls, it makes more sense (to me) to discuss it first.
Also fix some typos, massage some grammar, and (hopefully) improve precision
and clarity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162365 91177308-0d34-0410-b5e6-96231b3b80d8
Also, remove the FIXME about merging -analyzer-stats and the debug.Stats
checker. This would be a bad idea because simply running debug.Stats can
affect the output of -analyzer-stats.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162364 91177308-0d34-0410-b5e6-96231b3b80d8
Formatting includes:
- removing line wraps (Emacs Cmd-Q), to make text easier to read
- provide useful indentation
- call out caveats and notes more explictly
Stylistically, I prefer the document talk in 3rd person instead of "we". The
term "we" is unambiguous, and sometimes refers to different things. I've passed
over the existing paragraphs and made them speak more about specific entities
that compose the analyzer and what they do (e.g., ExprEngine) instead of "we"
referring to the analyzer.
Further, I have substituted some vague concepts such as "state" or "program
state" and replaced them with their precise implementation counterparts (e.g.,
ProgramState). This makes the document more technically precise throughout the
entire narrative, which would sometimes use vague terms and other times precise
terms.
I've placed several comments within the document, which can be seen with
***TMK/COMMENT***, which indicate places that need to be enhanced or clarified,
or called out as questions about intended bheavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162338 91177308-0d34-0410-b5e6-96231b3b80d8
Under -analyzer-ipa=basic-inlining, only C functions, blocks, and C++ static
member functions are inlined -- essentially, the calls that behave like simple
C function calls. This is essentially the behavior in Xcode 4.4.
C++ support still has some rough edges, and we don't want users to be worried
about them if they download and run their own checker. (In particular, the
massive number of false positives for analyzing LLVM comes from inlining
defensively-written code in contexts where more aggressive assumptions are
implicitly made. This problem is not unique to C++, but it is exacerbated by
the higher proportion of code that lives in header files in C++.)
The eventual goal is to be comfortable enough with C++ support (and simple
Objective-C support) to advance to -analyzer-ipa=inlining as the default
behavior. See the IPA design notes for more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162318 91177308-0d34-0410-b5e6-96231b3b80d8
First, when synthesizing an explicitly strong/retain/copy property
of Class type, don't pretend during compatibility checking that the
property is actually assign. Instead, resolve incompatibilities
by secretly changing the type of *implicitly* __unsafe_unretained
Class ivars to be strong. This is moderately evil but better than
what we were doing.
Second, when synthesizing the setter for a strong property of
non-retainable type, be sure to use objc_setProperty. This is
possible when the property is decorated with the NSObject
attribute. This is an ugly, ugly corner of the language, and
we probably ought to deprecate it.
The first is rdar://problem/12039404; the second was noticed by
inspection while fixing the first.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162244 91177308-0d34-0410-b5e6-96231b3b80d8
of matchers, categorized by type and fully expanded for the
context in which they can be used.
I used a script to generate this documentation which I'll want
to be scrunitized by a code review before checking it in.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162225 91177308-0d34-0410-b5e6-96231b3b80d8
This attempts to be a higher-level description of our inlining heuristics
and decision trees than the source, where the work is spread out between
ExprEngine (mostly in ExprEngineCallAndReturn.cpp) and CallEvent, with a
few other classes participating as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162073 91177308-0d34-0410-b5e6-96231b3b80d8
function arguments and arguments for variadic functions are of a particular
type which is determined by some other argument to the same function call.
Usecases include:
* MPI library implementations, where these attributes enable checking that
buffer type matches the passed MPI_Datatype;
* for HDF5 library there is a similar usecase as MPI;
* checking types of variadic functions' arguments for functions like
fcntl() and ioctl().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162067 91177308-0d34-0410-b5e6-96231b3b80d8
structure of how we're building concrete tools as well as tooling
infrastructure as part of the Clang project.
This documentation is definitely still rough. If anyone can improve it,
flesh it out, or help structure it in a more natural way, please, help!
=] This is not my forte, and patches here are more than welcome!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161855 91177308-0d34-0410-b5e6-96231b3b80d8
Kostya Serebryany
Daniel Jasper
Alexey Samsonov
Andy Gibbs
Richard Smith
John McCall
Douglas Gregor
Alexander Kornienko
Ted Kremenek
Jordan Rose
Manuel Klimek
Dmitri Gribenko
Anna Zaks
Chandler Carruth