PathDiagnostics are actually profiled and uniqued independently of the
path on which the bug occurred. This is used to merge diagnostics that
refer to the same issue along different paths, as well as by the plist
diagnostics to reference files created by the HTML diagnostics.
However, there are two problems with the current implementation:
1) The bug description is included in the profile, but some
PathDiagnosticConsumers prefer abbreviated descriptions and some
prefer verbose descriptions. Fixed by including both descriptions in
the PathDiagnostic objects and always using the verbose one in the profile.
2) The "minimal" path generation scheme provides extra information about
which events came from macros that the "extensive" scheme does not.
This resulted not only in different locations for the plist and HTML
diagnostics, but also in diagnostics being uniqued in the plist output
but not in the HTML output. Fixed by storing the "end path" location
explicitly in the PathDiagnostic object, rather than trying to find the
last piece of the path when the diagnostic is requested.
This should hopefully finish unsticking our internal buildbot.
llvm-svn: 162965
Basically, do the correct thing to fix the XML generation error, rather
than making it even worse by unilaterally dereferencing a null pointer.
llvm-svn: 162964
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
reanalyzed.
The policy on what to reanalyze should be in AnalysisConsumer with the
rest of visitation order logic.
There is no reason why ExprEngine needs to pass the Visited set to
CoreEngine, it can populate it itself.
llvm-svn: 162957
If the current path diagnostic does /not/ have files associated with it, we
were simply skipping on to the next diagnostic with 'continue'. But that
also skipped the close tag for the diagnostic's <dict> node.
Part of fixing our internal analyzer buildbot.
llvm-svn: 162939
initiated enum constant has the same value as another enum constant.
For instance:
enum test { A, B, C = -1, D, E = 1 };
Clang will warn that:
A and D both have value 0
B and E both have value 1
A few exceptions are made to keep the noise down. Enum constants which are
initialized to another enum constant, or an enum constant plus or minus 1 will
not trigger this warning. Also, anonymous enums are not checked.
llvm-svn: 162938
(__is_pod, __is_signed, etc.) to normal identifiers if they are
encountered in certain places in the grammar where we know that prior
versions of libstdc++ or libc++ use them, to still allow the use of
these keywords as type traits. Fixes <rdar://problem/9836262> and PR10184.
llvm-svn: 162937
Intorduces an abstraction for DynTypedNode which makes
is impossible to create in ways that introduced the bug;
also hides the implementation details of the template
magic away from the user and prepares the code for adding
QualType and TypeLoc bindings, as well as using DynTypedNode
instead of overloads for child and ancestor matching.
getNodeAs<T> was changed towards a non-pointer type, as
we'll want QualType and TypeLoc nodes to be returned
by value (the alternative would be to create new storage
which is prohibitively costly if we want to use it for
child / ancestor matching).
DynTypedNode is moved into a new header ASTTypeTraits.h,
as it is completely independent of the rest of the matcher
infrastructure - if the need comes up, we can move it to
a more common place.
The interface for users before the introduction of the
common storage change remains the same, minus the introduced
bug, for which a regression test was added.
llvm-svn: 162936
__objc_yes/__objc_no to (BOOL)1/(BOOL)0 when
BOOL is declared; otherwise it resorts to
default of 'signed char'. This is important to
selecting the correct Numeric API numberWithBool:
Can't have a clang test for this. Will checkin and
executable llvm test. // rdar://12156616
llvm-svn: 162922
within its own argument list. The original definition is used for the immediate
expansion, but the new definition is used for any subsequent occurences within
the argument list or after the expansion.
llvm-svn: 162906
This improves compatibility with gcc in this regard, and this file generation
can be ameliorated with GCOV_PREFIX and GCOV_PREFIX_STRIP. It's also useful if
your build directory doesn't specify -o <abspath> and it uses a recursive make
structure, so it's not relative to the toplevel.
Patch by Joshua Cranmer!
<rdar://problem/12179524>
llvm-svn: 162884
inlined function.
This resolves retain count checker false positives that are caused by
inlining ObjC and other methods. Essentially, if we are passing an
object to a method with "delegate" in the selector or a function pointer
as another argument, we should stop tracking the other parameters/return
value as far as the retain count checker is concerned.
llvm-svn: 162876
This heuristic addresses the case when a pointer (or ref) is passed
to a function, which initializes the variable (or sets it to something
other than '0'). On the branch where the inlined function does not
set the value, we report use of undefined value (or NULL pointer
dereference). The access happens in the caller and the path
through the callee would get pruned away with regular path pruning. To
solve this issue, we previously disabled diagnostic pruning completely
on undefined and null pointer dereference checks, which entailed very
verbose diagnostics in most cases. Furthermore, not all of the
undef value checks had the diagnostic pruning disabled.
This patch implements the following heuristic: if we pass a pointer (or
ref) to the region (on which the error is reported) into a function and
it's value is either undef or 'NULL' (and is a pointer), do not prune
the function.
llvm-svn: 162863
to define all macros for MIPS targets. Remove redundant virtual function
getArchDefines(). Two virtual functions for this task are really too much.
llvm-svn: 162853
CheckLValueConstantExpression.
Richard pointed out that using the address of a TLS variable is ok in a
core C++11 constant expression, as long as it isn't part of the eventual
result of constant expression evaluation. Having the check in
CheckLValueConstantExpression accomplishes this.
llvm-svn: 162850
Summary:
The problem was with the following sequence:
#pragma push_macro("long")
#undef long
#pragma pop_macro("long")
in case when "long" didn't represent a macro.
Fixed crash and removed code duplication for #undef/pop_macro case. Added regression tests.
Reviewers: doug.gregor, klimek
Reviewed By: doug.gregor
CC: cfe-commits, chapuni
Differential Revision: http://llvm-reviews.chandlerc.com/D31
llvm-svn: 162845
Jordan Rose