llvm-svn: 151030

stable mangling, since these lambdas can end up in multiple
translation units. Sema is responsible for deciding when this is the
case, because it's already responsible for choosing the mangling
number.

llvm-svn: 151029

llvm-svn: 151028

llvm-svn: 151027

llvm-svn: 151026

llvm-svn: 151025

construction. Simplify its interface, implementation, and users
accordingly as there is no longer an 'uninitialized' state to check for.
Also, fixes a bug lurking in the interface as there was one method that
didn't correctly check for initialization.

llvm-svn: 151024

Also add SB API's to set this callback, and to enable the log channels.

llvm-svn: 151018

initializers of data members (both static and non-static).

llvm-svn: 151017

know where users will be added. Because of this, it cannot use
Builder.GetInsertPoint at all.

This patch
* removes the FIXME about adding the assert.
* adds a comment explaining hy we don't have one.
* removes a broken logic that only works for some callers and is not needed
  since r150884.
* adds an assert to caller that would have caught the bug fixed by r150884.

llvm-svn: 151015

llvm-svn: 151014

llvm-svn: 151013

Have ScanReachableSymbols reported reachable regions.  Fixes a false positive with nested array literals.  <rdar://problem/10686586>

llvm-svn: 151012

default arguments of function parameters. This simple-sounding task is
complicated greatly by two issues:

  (1) Default arguments aren't actually a real context, so we need to
  maintain extra state within lambda expressions to track when a
  lambda was actually in a default argument.
  (2) At the time that we parse a default argument, the FunctionDecl
  doesn't exist yet, so lambda closure types end up in the enclosing
  context. It's not clear that we ever want to change that, so instead
  we introduce the notion of the "effective" context of a declaration
  for the purposes of name mangling.

llvm-svn: 151011

llvm-svn: 151010

objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a 
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.

Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and 
ExecutionContextRef objects.

llvm-svn: 151009

llvm-svn: 151008

llvm-svn: 151007

llvm-svn: 151006

llvm-svn: 151005

from the one stored in the PCH/AST, while trying to load a SLocEntry.

We verify that all files of the PCH did not change before loading it but this is not enough because:

- The AST may have been 1) kept around, 2) to do queries on it.
- We may have 1) verified the PCH and 2) started parsing.

Between 1) and 2) files may change and we are going to have crashes because the rest of clang
cannot deal with the ASTReader failing to read a SLocEntry.

Handle this by recovering gracefully in such a case, by initializing the SLocEntry
with the info from the PCH/AST as well as reporting failure by the ASTReader.

rdar://10888929

llvm-svn: 151004

llvm-svn: 151003

ecx = mov eax
al  = mov ch
The second copy is not a nop because the sub-indices of ecx,ch is not the
same of that of eax/al.

Re-enabled machine-cp.
PR11940

llvm-svn: 151002

explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.

llvm-svn: 151001

llvm-svn: 150998

llvm-svn: 150997

llvm-svn: 150996

Recording nested macro expansions is not useful, plus it fixes rdar://10893630

llvm-svn: 150995

the 'invariant.load' metadata tag onto those loads.
// rdar://10840980

llvm-svn: 150994

tests.

llvm-svn: 150993

llvm-svn: 150992

Patch by Dmitry Vyukov <dvyukov@google.com>.

Also add the relevant files to the Xcode project.

llvm-svn: 150991

Patch to fix the main.cpp compile error submitted by Dmitry Vyukov <dvyukov@google.com>.
Also add a Makefile, plus some modification to main.cpp.

llvm-svn: 150990

llvm-svn: 150989

checks:

- unix.Malloc - Checks for memory leaks, double free, use-after-free.
- unix.cstring.NullArg - Checks for null pointers passed as arguments to
CString functions + evaluates CString functions.
- unix.cstring.BadSizeArg - Checks for common anti-patterns in
strncat size argument.

llvm-svn: 150988

and introducing the lambda closure type and its function call
operator. Previously, we assumed that the lambda closure type would
land directly in the current context, and not some parent context (as
occurs with linkage specifications). Thanks to Richard for the test case.

llvm-svn: 150987

modern meta-data translation by commenting out private ivar
declarations in user source. Also, added several tests.

llvm-svn: 150985

of that variable; it will need to be recomputed with the resolved
type.

llvm-svn: 150984

llvm-svn: 150983

name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each lambda
as part of the lambda closure type, and maintain this value within
Sema.

Note that there are a several pieces still missing:
  - We still get the linkage of lambda expressions wrong
  - We aren't properly numbering or mangling lambda expressions that
  occur in default function arguments or in data member initializers.
  - We aren't (de-)serializing the lambda numbering tables

llvm-svn: 150982