| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 162930
|
| |
|
|
|
|
| |
individual flags.
llvm-svn: 162929
|
| |
|
|
| |
llvm-svn: 162928
|
| |
|
|
| |
llvm-svn: 162927
|
| |
|
|
|
|
|
|
|
|
|
| |
__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
|
| |
|
|
|
|
|
| |
be filled in; they won't if the lambda's declarator has an invalid type. Instead
take the parameters from the declarator directly.
llvm-svn: 162904
|
| |
|
|
|
|
| |
support the '-analyzer-config key=val' variant.
llvm-svn: 162891
|
| |
|
|
|
|
| |
Also update the tests that rely on c++98 to explicitly mention that.
llvm-svn: 162890
|
| |
|
|
|
|
|
|
| |
passing additional parameters to a tool.
Use this to fix a FIXME in testing code.
llvm-svn: 162889
|
| |
|
|
| |
llvm-svn: 162886
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Thanks Jordan.
llvm-svn: 162875
|
| |
|
|
|
|
|
|
| |
could not be attached to a CFTypeRef.
Fixes <rdar://problem/12197822>
llvm-svn: 162872
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
non-pointer types with a pointer representation correctly. PR13660.
llvm-svn: 162862
|
| |
|
|
|
|
| |
The patch suggested by Brad Smith.
llvm-svn: 162858
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 162852
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
when assignment expression in conditional invloves
property reference. // rdar://11066598
llvm-svn: 162846
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
The patch suggested by Logan Chien.
llvm-svn: 162840
|
| |
|
|
|
|
| |
changing the group to the singular to match the diagnostic better.
llvm-svn: 162838
|
| |
|
|
|
|
|
| |
VisitVarDecl should return Error(E), and we should test that the address
of a TLS var can't be used as a constexpr.
llvm-svn: 162837
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This makes Clang produce an error for code such as:
__thread int x;
int *p = &x;
The lvalue of a thread-local variable cannot be evaluated at compile
time.
llvm-svn: 162835
|
| |
|
|
|
|
|
|
|
| |
a comma separated collection of key:value pairs (which are strings). This
allows a general way to provide analyzer configuration data from the command line.
No clients yet.
llvm-svn: 162827
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In C++, objects being returned on the stack are actually copy-constructed into
the return value. That means that when a temporary is returned, it still has
to be destroyed, i.e. the returned expression will be wrapped in an
ExprWithCleanups node. Our "returning stack memory" checker needs to look
through this node to see if we really are returning an object by value.
PR13722
llvm-svn: 162817
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Summary: Keep history of macro definitions and #undefs with corresponding source locations, so that we can later find out all macros active in a specified source location. We don't save the history in PCH (no need currently). Memory overhead is about sizeof(void*)*3*<number of macro definitions and #undefs>+<in-memory size of all #undef'd macros>
I've run a test on a file composed of 109 .h files from boost 1.49 on x86-64 linux.
Stats before this patch:
*** Preprocessor Stats:
73222 directives found:
19171 #define.
4345 #undef.
#include/#include_next/#import:
5233 source files entered.
27 max include stack depth
19210 #if/#ifndef/#ifdef.
2384 #else/#elif.
6891 #endif.
408 #pragma.
14466 #if/#ifndef#ifdef regions skipped
80023/451669/1270 obj/fn/builtin macros expanded, 85724 on the fast path.
127145 token paste (##) operations performed, 11008 on the fast path.
Preprocessor Memory: 5874615B total
BumpPtr: 4399104
Macro Expanded Tokens: 417768
Predefines Buffer: 8135
Macros: 1048576
#pragma push_macro Info: 0
Poison Reasons: 1024
Comment Handlers: 8
Stats with this patch:
...
Preprocessor Memory: 7541687B total
BumpPtr: 6066176
Macro Expanded Tokens: 417768
Predefines Buffer: 8135
Macros: 1048576
#pragma push_macro Info: 0
Poison Reasons: 1024
Comment Handlers: 8
In my test increase in memory usage is about 1.7Mb, which is ~28% of initial preprocessor's memory usage and about 0.8% of clang's total VMM allocation.
As for CPU overhead, it should only be noticeable when iterating over all macros, and should mostly consist of couple extra dereferences and one comparison per macro + skipping of #undef'd macros. It's less trivial to measure, though, as the preprocessor consumes a very small fraction of compilation time.
Reviewers: doug.gregor, klimek, rsmith, djasper
Reviewed By: doug.gregor
CC: cfe-commits, chandlerc
Differential Revision: http://llvm-reviews.chandlerc.com/D28
llvm-svn: 162810
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
into the correct types when pulling them out in the result
callback in a type safe way.
This is also the base change for multiple things that will
allow handling things more generally and thus supporting more
of the AST, especially handling Type nodes.
Patch contributed by Michael Diamond.
llvm-svn: 162804
|
| |
|
|
|
|
|
|
| |
and when used in property type declaration, is handled as type
attribute. Do not issue the warning when declaraing the property.
// rdar://12173491
llvm-svn: 162801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Subj.
Reviewers: chandlerc, klimek, djasper
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D29
llvm-svn: 162798
|
| |
|
|
| |
llvm-svn: 162797
|
| |
|
|
| |
llvm-svn: 162796
|
| |
|
|
|
|
| |
ExtWarn and the other a vanilla warning. This addresses PR13705, where const char const * wouldn't warn unless -pedantic was specified under the right conditions.
llvm-svn: 162793
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, CallEventManager::getCaller was looking at the call site for
an inlined call and trying to see what kind of call it was, but it only
checked for CXXConstructExprClass. (It's not using an isa<> here to avoid
doing three more checks on the the statement class.)
This caused an unreachable when we actually did inline the constructor of a
temporary object.
PR13717
llvm-svn: 162792
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When exiting a function, the analyzer looks for the last statement in the
function to see if it's a return statement (and thus bind the return value).
However, the search for "the last statement" was accepting statements that
were in implicitly-generated inlined functions (i.e. destructors). So we'd
go and get the statement from the destructor, and then say "oh look, this
function had no explicit return...guess there's no return value". And /that/
led to the value being returned being declared dead, and all our leak
checkers complaining.
llvm-svn: 162791
|
| |
|
|
|
|
|
|
| |
variables without a storage class within a function, to implement
CUDA B.2.5: "__shared__ and __constant__ variables have implied static
storage [duration]."
llvm-svn: 162788
|
| |
|
|
| |
llvm-svn: 162787
|
| |
|
|
| |
llvm-svn: 162786
|
| |
|
|
|
|
|
|
| |
We still need to translate the string, but this at least gets us one step
closer to using the more general EmitAsmStmt() codegen function. No functional
change intended.
llvm-svn: 162785
|
| |
|
|
|
|
|
| |
the constraints, so in the interim we speculatively assume a 'r' constraint.
This is expected to work for most cases on x86.
llvm-svn: 162784
|
| |
|
|
|
|
|
|
| |
AsmStmts. This function is only used by GCCAsmStmts, however. Constraints need
to be properly computed before MSAsmStmts can use EmitAsmStmt. No functional
change intended.
llvm-svn: 162776
|
| |
|
|
| |
llvm-svn: 162773
|
| |
|
|
|
|
|
|
| |
No test case since this is a debug option that we will never turn on by
default since it makes the leak checkers much less useful. (We'll only report
leaks at the end of analysis if -analyzer-purge=none.)
llvm-svn: 162772
|
| |
|
|
| |
llvm-svn: 162768
|
| |
|
|
|
|
|
| |
- The increment needs to be signed value to preserve the original value when
its data type is larger than 64-bit integer.
llvm-svn: 162766
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This warns in two specific situations:
1) For potentially swapped function arguments, e.g.
void foo(bool, float);
foo(1.7, false);
2) Misplaced brackets around function call arguments, e.g.
bool InRange = fabs(a - b < delta);
Where the last argument in a function call is implicitly converted
from bool to float, and the function returns a float which gets
implicitly converted to bool.
Patch by Andreas Eckleder!
llvm-svn: 162763
|
| |
|
|
|
|
| |
Path by Brooks Davis, tests and fixes from me.
llvm-svn: 162761
|