, when we return a symbol reachable to the malloced one via pointer
arithmetic.

llvm-svn: 151121

llvm-svn: 151120

llvm-svn: 151118

function call (or a comma expression with a function call on its right-hand
side), possibly parenthesized, then the return type is not required to be
complete and a temporary is not bound. Other subexpressions inside a decltype
expression do not get this treatment.

This is implemented by deferring the relevant checks for all calls immediately
within a decltype expression, then, when the expression is fully-parsed,
checking the relevant constraints and stripping off any top-level temporary
binding.

Deferring the completion of the return type exposed a bug in overload
resolution where completion of the argument types was not attempted, which
is also fixed by this change.

llvm-svn: 151117

llvm-svn: 151112

crash.  This can speedup the process of generating a delta reduced test case.
rdar://10905465

llvm-svn: 151109

any implementation in tu was not being translated.

llvm-svn: 151106

llvm-svn: 151103

llvm-svn: 151102

that 'this' can be used in the brace-or-equal-initializer of a
non-static data member, and C++11 [expr.prim.lambda]p9, which says
that lambda expressions not in block scope can have no captures, side
fully with C++11 [expr.prim.general]p4 by allowing 'this' to be
captured within these initializers. This seems to be the intent of
non-static data member initializers.

llvm-svn: 151101

llvm-svn: 151100

itself crashes.

llvm-svn: 151095

prefixes. It seems only crtbegin.o uses the strange formatting.

llvm-svn: 151094

the linker toolchainness a bit more thoroughly. It used to work this
way, but hit buildbot issues. Hopefully subsequent fixes have addressed
those problems, but I'll be watching the bots.

llvm-svn: 151090

rdar://problem/10904479

llvm-svn: 151089

up the build enviroment.

llvm-svn: 151087

expression after we've finished the function body of the corresponding
function call operator. Otherwise, ActOnFinishFunctionBody() will see
the (unfinished) evaluation context of the lambda expression
itself. Fixes PR12031.

llvm-svn: 151082

is non-null when diagnosing a broken attempt to write a for-range-statement.

llvm-svn: 151081

When calling a non variadic format function(vprintf, vscanf, NSLogv, …), warn if the format string argument is a parameter that is not itself declared as a format string with compatible format.

llvm-svn: 151080

arguments. There are two aspects to this:

  - Make sure that when marking the declarations referenced in a
  default argument, we don't try to mark local variables, both because
  it's a waste of time and because the semantics are wrong: we're not
  in a place where we could capture these variables again even if it
  did make sense.
  - When a lambda expression occurs in a default argument of a
  function template, make sure that the corresponding closure type is
  considered dependent, so that it will get properly instantiated. The
  second bit is a bit of a hack; to fix it properly, we may have to
  rearchitect our handling of default arguments, parsing them only
  after creating the function definition. However, I'd like to
  separate that work from the lambdas work.

llvm-svn: 151076

that's installed.

llvm-svn: 151058

llvm-svn: 151037

llvm-svn: 151036

and useable while debugging.

llvm-svn: 151033

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: 151027

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

llvm-svn: 151017

llvm-svn: 151014

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

llvm-svn: 151008

llvm-svn: 151007

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

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: 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