While there is now some duplication between SimpleCall and the CXXInstanceCall
sub-hierarchy, this is much better than copy-and-pasting the devirtualization
logic shared by both instance methods and destructors.
An unfortunate side effect is that there is no longer a single CallEvent type
that corresponds to "calls written as CallExprs". For the most part this is a
good thing, but the checker callback eval::Call still takes a CallExpr rather
than a CallEvent (since we're not sure if we want to allow checkers to
evaluate other kinds of calls). A mistake here will be caught by a cast<> in
CheckerManager::runCheckersForEvalCall.
No functionality change.
llvm-svn: 161809
...and /do/ strip CXXBaseObjectRegions when casting to a virtual base class.
This allows us to enforce the invariant that a CXXBaseObjectRegion can always
provide an offset for its base region if its base region has a known class
type, by only allowing virtual bases and direct non-virtual bases to form
CXXBaseObjectRegions.
This does mean some slight problems for our modeling of dynamic_cast, which
needs to be resolved by finding a path from the current region to the class
we're trying to cast to.
llvm-svn: 161797
Not only look for the comment near the declaration itself, but also walk the
redeclaration chain: the previous declaration might have had a documentation
comment.
llvm-svn: 161722
when we don't need to split.
In some cases we know that a method cannot have a different
implementation in a subclass:
- the class is declared in the main file (private)
- all the method declarations (including the ones coming from super
classes) are in the main file.
This can be improved further, but might be enough for the heuristic.
(When we are too aggressive splitting the state, efficiency suffers.
When we fail to split the state coverage might suffer.)
llvm-svn: 161681
things going on here that were problematic:
- We were missing the actual access check, or rather, it was suppressed
on account of being a redeclaration lookup.
- The access check would naturally happen during delay, which isn't
appropriate in this case.
- We weren't actually emitting dependent diagnostics associated with
class templates, which was unfortunate.
- Access was being propagated incorrectly for friend method declarations
that couldn't be matched at parse-time.
llvm-svn: 161652
The old behavior was to re-scan any files (like modules) where we may have
directives but won't actually be parsing during the -verify invocation.
Now, we keep the old behavior in Debug builds as a sanity check (though
modules are a known entity), and expect all legitimate directives to come
from comments seen by the preprocessor.
This also affects the ARC migration tool, which captures diagnostics in
order to filter some out. This change adds an explicit cleanup to
CaptureDiagnosticsConsumer in order to let its sub-consumer handle the
real end of diagnostics.
This was originally split into four patches, but the tests do not run
cleanly without all four, so I've combined them into one commit.
Patches by Andy Gibbs, with slight modifications from me.
llvm-svn: 161650
This also provides isConst/Volatile/Restrict on FunctionTypes to coalesce
the implementation with other callers (& update those other callers).
Patch contributed by Sam Panzer (panzer@google.com).
llvm-svn: 161647
This makes it faster to access and invalidate bindings with symbolic offsets
by only computing this information once.
No intended functionality change.
llvm-svn: 161635
This was triggering -Woverloaded-virtual, but there's really no reason for
the cast version to be virtual anyway. It just calls through to the QualType
entry point.
llvm-svn: 161631
An ASTContext's RecordLayoutInfo can only be used to look up offsets of
direct base classes, and we need the offset to make non-symbolic bindings
in RegionStore. This change makes sure that we have one layer of
CXXBaseObjectRegion for each base we are casting through.
This was causing crashes on an internal buildbot.
llvm-svn: 161621
This is an initial (unoptimized) version. We split the path when
inlining ObjC instance methods. On one branch we always assume that the
type information for the given memory region is precise. On the other we
assume that we don't have the exact type info. It is important to check
since the class could be subclassed and the method can be overridden. If
we always inline we can loose coverage.
Had to refactor some of the call eval functions.
llvm-svn: 161552
Unfortunately, generalized region printing is very difficult:
- ElementRegions are used both for casting and as actual elements.
- Accessing values through a pointer means going through an intermediate
SymbolRegionValue; symbolic regions are untyped.
- Referring to implicitly-defined variables like 'this' and 'self' could be
very confusing if they come from another stack frame.
We fall back to simply not printing the region name if we can't be sure it
will print well. This will allow us to improve in the future.
llvm-svn: 161512
RegionStore currently uses a (Region, Offset) pair to describe the locations
of memory bindings. However, this representation breaks down when we have
regions like 'array[index]', where 'index' is unknown. We used to store this
as (SubRegion, 0); now we mark them specially as (SubRegion, SYMBOLIC).
Furthermore, ProgramState::scanReachableSymbols depended on the existence of
a sub-region map, but RegionStore's implementation doesn't provide for such
a thing. Moving the store-traversing logic of scanReachableSymbols into the
StoreManager allows us to eliminate the notion of SubRegionMap altogether.
This fixes some particularly awkward broken test cases, now in
array-struct-region.c.
llvm-svn: 161510
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...
There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.
Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.
Review by Sean Silva and Richard Smith.
llvm-svn: 161501
A conditional operator between glvalues of types cv1 T and cv2 T produces a
glvalue if the expressions are of the same value kind and one of cv1 and cv2
is a subset of the other.
A conditional operator between two null pointer constants is permitted if one
of them is of type std::nullptr_t.
llvm-svn: 161476
Warns on anti-patterns/typos in the 'size' argument to strncat. The
correct size argument should look like the following:
- strncat(dst, src, sizeof(dst) - strlen(dest) - 1);
We warn on:
- sizeof(dst)
- sizeof(src)
- sizeof(dst) - strlen(dst)
- sizeof(src) - anything
(This has been implemented in void Sema::CheckStrncatArguments().)
llvm-svn: 161440
The implementation also includes a Relax NG schema and tests for the schema
itself. The schema is used in c-index-test to verify that XML documents we
produce are valid. In order to do the validation, we add an optional libxml2
dependency for c-index-test.
Credits for CMake part go to Doug Gregor. Credits for Autoconf part go to Eric
Christopher. Thanks!
llvm-svn: 161431
This is useful for example for %n in printf, which expects
a pointer to int with the same logic for checking as %d
would have in scanf.
llvm-svn: 161407
update implementation to match. An elidable, non-trivial constructor call is a
side-effect under this definition, but wasn't under the old one, because we are
not required to evaluate it even though it may have an effect.
Also rationalize checking for volatile reads: just look for lvalue-to-rvalue
conversions on volatile glvalues, and ignore whether a DeclRefExpr etc is for
a volatile variable.
llvm-svn: 161393
included in warning groups. Warning groups can only contain warnings, because only
warnings can be mapped to errors or ignored.
This caught a few diagnostics that were incorrectly in diagnostic groups, and
could have resulted in a compiler crash when those diagnostic groups were mapped.
Fixes <rdar://problem/12044436>
llvm-svn: 161389
Only warnings should be in warning groups. This was causing an assertion failure in
code using pragmas to map -Wignored-attributes to ignored, but this kind of
diagnostic mapping is disallowed for builtin errors. We should just wire
up tablegen to reject errors being in diagnostic groups.
llvm-svn: 161376
Instead of sprinkling dynamic type info propagation throughout
ExprEngine, the added checker would add the more precise type
information on known APIs (Ex: ObjC alloc, new) and propagate
the type info in other cases (ex: ObjC init method, casts (the second is
not implemented yet)).
Add handling of ObjC alloc, new and init to the checker.
llvm-svn: 161357
The one caller that's surrounded by nearby code manipulating the underlying
evaluation context list is left unmodified for readability.
Review by Sean Silva and Richard Smith.
llvm-svn: 161355
Doxygen manual claims that multiple \brief or \returns commands will be merged
together, but actual behavior is different (second \brief command becomes a
part of a discussion, second \returns becomes a "Returns: blah" paragraph on
its own). Anyway, it seems to be a bad idea to use multiple \brief or \returns
commands in a single command.
llvm-svn: 161325
'clang-cpp'.
For now, the test uses "REQUIRES: shell" to determine if the host system
supports "ln -s", which it uses to create a 'clang-cpp' symlink. This is a bit
hacky and should likely be directly supported by lit.cfg.
llvm-svn: 161317
we know whether the function is virtual. But check it as soon as we do know;
in some cases we don't need to wait for an instantiation.
llvm-svn: 161316
Because of this, we would previously emit NO path notes when a parameter
is constrained to null (because there are no stores). Now we show where we
made the assumption, which is much more useful.
llvm-svn: 161280
In the following code, find the type of the symbolic receiver by
following it and updating the dynamic type info in the state when we
cast the symbol from id to MyClass *.
MyClass *a = [[self alloc] init];
return 5/[a testSelf];
llvm-svn: 161264
The only caveat is renumbering CXCommentKind enum for aesthetic reasons -- this
breaks libclang binary compatibility, but should not be a problem since API is
so new.
This also fixes PR13372 as a side-effect.
llvm-svn: 161087
Clear the FileManager's stat cache in between running
translation units, as the stat cache loaded from a pch
is only valid for one compiler invocation.
llvm-svn: 161047
on object pointers and whether pointer arithmetic on object pointers
is supported. Make ObjFW interpret subscripts as pseudo-objects.
Based on a patch by Jonathan Schleifer.
llvm-svn: 161028
This removes explicit checks for 'this' and 'self' from
Store::enterStackFrame. It also removes getCXXThisRegion() as a virtual
method on all CallEvents; it's now only implemented in the parts of the
hierarchy where it is relevant. Finally, it removes the option to ask
for the ParmVarDecls attached to the definition of an inlined function,
saving a recomputation of the result of getRuntimeDefinition().
No visible functionality change!
llvm-svn: 161017
Previously, we were only checking the origin expressions of inlined calls.
Checkers using the generic postCall and older postObjCMessage callbacks were
ignored. Now that we have CallEventManager, it is much easier to create
a CallEvent generically when exiting an inlined function, which we can then
use for post-call checks.
No test case because we don't (yet) have any checkers that depend on this
behavior (which is why it hadn't been fixed before now).
llvm-svn: 161005
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.
Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.
llvm-svn: 160998
type of generated call to super dealloc is 'void'
and asserts if user's dealloc is not of 'void type.
This rule must be enforced in clang front-end (with a
fixit) if this is not the case, instead of asserting in CodeGen.
// rdar://11987838
llvm-svn: 160993
- Retrieves the type of the object/receiver from the state.
- Binds self during stack setup.
- Only explores the path on which the method is inlined (no
bifurcation to explore the path on which the method is not inlined).
llvm-svn: 160991
This ensures that it is valid to reference-count any CallEvents, and we
won't accidentally try to reclaim a CallEvent that lives on the stack.
It also hides an ugly switch statement for handling CallExprs!
There should be no functionality change here.
llvm-svn: 160986
While '%n' can be used for evil in an attacker-controlled format string, there
isn't any acute danger in using it in a literal format string with an argument
of the appropriate type.
llvm-svn: 160984
This allows us to get around the C++ "virtual constructor" problem
when we'd like to create a CallEvent from an ExplodedNode, an inlined
StackFrameContext, or another CallEvent. The solution has three parts:
- CallEventManager uses a BumpPtrAllocator to allocate CallEvent-sized
memory blocks. It also keeps a cache of freed CallEvents for reuse.
- CallEvents all have protected copy constructors, along with cloneTo()
methods that use placement new to copy into CallEventManager-managed
memory, vtables intact.
- CallEvents owned by CallEventManager are now wrapped in an
IntrusiveRefCntPtr. Going forwards, it's probably a good idea to create
ALL CallEvents through the CallEventManager, so that we don't accidentally
try to reclaim a stack-allocated CallEvent.
All of this machinery is currently unused but will be put into use shortly.
llvm-svn: 160983
hex: ) during comment parsing.
Now internal representation of plain text in comment AST does not contain
character references, but the characters themselves.
llvm-svn: 160891
Clang's -Wformat fix-its currently suggest using "%zu" for values of
type size_t (in C99 or C++11 mode). However, for a type such as
std::vector<T>::size_type, it does not notice that type is actually
typedeffed to size_t, and instead suggests a format for the underlying
type, such as "%lu" or "%u".
This commit makes the format string fix mechanism walk the typedef chain
so that it notices if the type is size_t, even if that isn't "at the
top".
llvm-svn: 160886
Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.
Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.
llvm-svn: 160885
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
After discussion, the type-based dispatch was decided to be bad for
maintenance and made it very easy for subtle bugs to creep in. Instead,
we'll just be very careful when we do have to allocate these on the heap.
llvm-svn: 160817
Most of the logic here is fairly simple; the interesting thing is that
we now distinguish complete constructors from base or delegate constructors.
We also make sure to cast to the base class before evaluating a constructor
or destructor, since non-virtual base classes may behave differently.
This includes some refactoring of VisitCXXConstructExpr and VisitCXXDestructor
in order to keep ExprEngine.cpp as clean as possible (leaving the details for
ExprEngineCXX.cpp).
llvm-svn: 160806
This modifies BugReporter and friends to handle CallEnter and CallExitEnd
program points that came from implicit call CFG nodes (read: destructors).
This required some extra handling for nested implicit calls. For example,
the added multiple-inheritance test case has a call graph that looks like this:
testMultipleInheritance3
~MultipleInheritance
~SmartPointer
~Subclass
~SmartPointer
***bug here***
In this case we correctly notice that we started in an inlined function
when we reach the CallEnter program point for the second ~SmartPointer.
However, when we reach the next CallEnter (for ~Subclass), we were
accidentally re-using the inner ~SmartPointer call in the diagnostics.
Rather than guess if we saw the corresponding CallExitEnd based on the
contents of the active path, we now just ask the PathDiagnostic if there's
any known stack before popping off the top path.
(A similar issue could have occured without multiple inheritance, but there
wasn't a test case for it.)
llvm-svn: 160804
- Some cleanup(the TODOs) will be done after ObjC method inlining is
complete.
- Simplified CallEvent::getDefinition not to require ISDynamicDispatch
parameter.
- Also addressed Jordan's comments from r160530.
llvm-svn: 160768
and became necessary with the change to require BindableMatchers
for binding.
Also fixes PR 13445: "hasSourceExpression only works for implicit casts".
llvm-svn: 160716
Rather than adding a ContainsUnexpandedParameterPack bit to essentially every
AST node, we tunnel the bit directly up to the surrounding lambda expression
when we reach a context where an unexpanded pack can not normally appear.
Thus any statement or declaration within a lambda can now potentially contain
an unexpanded parameter pack.
llvm-svn: 160705
A warning was added in r150128 for returning non-C compatible
user-defined types from functions with C linkage.
This makes the text more clear for the case when the type isn't
decidedly non-C compatible, but incomplete.
llvm-svn: 160681
as per Chandler's request:
- introduces a new matcher base type BindableMatcher that
provides the bind() call
- makes all dynamic-cast matcher creation functions return
BindableMatchers; the special case about dynamic-cast
matchers is that the node they match on and the node
their child matchers match on are the same node, just
casted to a different type; thus, there is no ambiguity
on what bind() matches on; additionally, those are the
matchers that we name with nouns in the matcher language,
so it's easy for users to intuitively know which matchers
are bindable
To make this change possible, we got rid of a non-orthogonal
implementation of thisPointerType, which had an implicit
dynamic-cast matcher from CallExpr to CXXMemberCallExpr; as
alternative, we now provide a memberCall dynamic-cast matcher
and thisPointerType is a predicate on CXXMemberCallExpr.
Last, the ArgumentAdaptingMatcher is actually not required
for the implementation of makeDynCastAllOfComposite - this
simplification makes it more obvious where the bind() call
can be used based on the matcher creation function types.
llvm-svn: 160673
variables that have static storage duration, it removes debug info on the
emitted initializer function but not all debug info about this variable.
llvm-svn: 160659
scope to -Wc++11-extensions. Move extra semicolon after member function
definition diagnostic out of -pedantic, since C++ allows a single semicolon
there. Keep it in -Wextra-semi, though, since it's still questionable.
llvm-svn: 160618
change once it's been assigned. It can change in two ways:
1) In a template instantiation, the context declaration should be the
instantiated declaration, not the declaration in the template.
2) If a lambda appears in the pattern of a variadic pack expansion, the
mangling number will depend on the pack length.
llvm-svn: 160614
by index. This is useful if the user does not document all arguments, and we
can't find a particular argument by index via :nth-of-type() CSS selector.
llvm-svn: 160595
HTML fragment.
For testing, c-index-test now has even more output:
* HTML rendering of a comment
* comment AST tree dump in S-expressions like Comment::dump(), but implemented
* with libclang APIs.
llvm-svn: 160577
assembly.
By default, we don't emit IR for MS-style inline assembly (see r158833 as to
why). This is strictly for testing purposes and should not be enabled with the
expectation that things will work. This is a temporary flag and will be removed
once MS-style inline assembly is fully supported.
llvm-svn: 160573
The CFG creates dummy DeclStmts with one Decl per statement, and it has
to do so from last to first in order to build the graph correctly.
llvm-svn: 160560
While we still want to consider this a hard error (non-POD variadic args are
normally a DefaultError warning), delaying the diagnostic allows us to give
better error messages, which also match the usual non-POD errors more closely.
In addition, this change improves the diagnostic messages for format string
argument type mismatches by passing down the type of the callee, so we can
say "variadic method" or "variadic function" appropriately.
<rdar://problem/11825593>
llvm-svn: 160517
This macro was being unconditionally set to zero, preceded by a FIXME comment.
This fixes <rdar://problem/11845441>. Patch by Michael Gottesman!
llvm-svn: 160491
Panzer. I've not been able to trigger a failure caused by this, so no test yet.
Also included is a small change from Paul Robinson to only consider the
FailureKind if the overload candidate did actually fail.
llvm-svn: 160470
As pointed out by Anna, we only differentiate between explicit message sends
This also adds support for ObjCSubscriptExprs, which are basically the same
as properties in many ways. We were already checking these, but not emitting
nice messages for them.
This depends on the llvm::PointerIntPair change in r160456.
llvm-svn: 160461
Anna Zaks