llvm-svn: 162880

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

llvm-svn: 162866

llvm-svn: 162865

partially).

(Addresses a regression from r162790.)

llvm-svn: 162864

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

Reversing the logic since C99 mode is actually not an extension.  Also, 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

Can't use __thread in init.c because it doesn't have a triple.

llvm-svn: 162836

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

[super dealloc].  rdar://problem/11141872

llvm-svn: 162833

llvm-svn: 162830

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

llvm-svn: 162800

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

Splitting the duplicated decl spec extension warning into two: one is an 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

llvm-svn: 162790

llvm-svn: 162789

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