1) Support the case when realloc fails to reduce False Positives. (We
essentially need to restore the state of the pointer being reallocated.)

2) Realloc behaves differently under special conditions (from pointer is
null, size is 0). When detecting these cases, we should consider
under-constrained states (size might or might not be 0). The
old version handled this in a very hacky way. The code did not
differentiate between definite and possible (no consideration for
under-constrained states). Further, after processing each special case,
the realloc processing function did not return but chained to the next
special case processing. So you could end up in an execution in which
you first see the states in which size is 0 and realloc ~ free(),
followed by the states corresponding to size is not 0 followed by the
evaluation of the regular realloc behavior.

llvm-svn: 150402

CXXRecordDecl in a way that actually makes some sense:
  - LambdaExpr contains all of the information for initializing the
  lambda object, including the capture initializers and associated
  array index variables.
  - CXXRecordDecl's LambdaDefinitionData contains the captures, which
  are needed to understand the captured variable references in the
  body of the lambda.

llvm-svn: 150401

synthesize a by-copy captured array in a lambda. This information will
be needed by IR generation.

llvm-svn: 150396

llvm-svn: 150394

LambdaExpr over to the CXXRecordDecl. This allows us to eliminate the
back-link from the closure type to the LambdaExpr, which will simplify
and lazify AST deserialization.

llvm-svn: 150393

llvm-svn: 150390

while reworking how we handle wanting to emit only parts of structures.

Fixes PR11970.

llvm-svn: 150388

1358, 1360, 1452 and 1453.
 - Instantiations of constexpr functions are always constexpr. This removes the
   need for separate declaration/definition checking, which is now gone.
 - This makes it possible for a constexpr function to be virtual, if they are
   only dependently virtual. Virtual calls to such functions are not constant
   expressions.
 - Likewise, it's now possible for a literal type to have virtual base classes.
   A constexpr constructor for such a type cannot actually produce a constant
   expression, though, so add a special-case diagnostic for a constructor call
   to such a type rather than trying to evaluate it.
 - Classes with trivial default constructors (for which value initialization can
   produce a fully-initialized value) are considered literal types.
 - Classes with volatile members are not literal types.
 - constexpr constructors can be members of non-literal types. We do not yet use
   static initialization for global objects constructed in this way.

llvm-svn: 150359

this functionality.

llvm-svn: 150358

llvm-svn: 150353

[dcl.type.simple]p4, which treats all xvalues as returning T&&. We had
previously implemented a pre-standard variant of decltype() that
doesn't cope with, e.g., static_ast<T&&>(e) very well.

llvm-svn: 150348

id-expression 'x' will compute the type based on the assumption that
'x' will be captured, even if it isn't captured, per C++11
[expr.prim.lambda]p18. There are two related refactors that go into
implementing this:

  1) Split out the check that determines whether we should capture a
  particular variable reference, along with the computation of the
  type of the field, from the actual act of capturing the
  variable. 
  2) Always compute the result of decltype() within Sema, rather than
  AST, because the decltype() computation is now context-sensitive.

llvm-svn: 150347

Proper initializer list support for new expressions and type construct expressions. Array new still missing.

llvm-svn: 150346

assignment operator, per C++ [expr.prim.lambda]p19. Make it so.

llvm-svn: 150345

Change the way we store initialization kinds so that all direct inits can distinguish between list and parens form. This allows us to correctly diagnose the last test cases from litb.

llvm-svn: 150343

llvm-svn: 150342

r149987 changed the way parsing happens inside an @implementation;
it aggregates the declarations inside and reports them together as a DeclGroup.
This had the side effect that function declarations were reported together with
their definition, while the rewriter expected for function declarations to be
reported immediately to the consumer and thus not have a body.

Fix this by having the rewriter actually check with isThisDeclarationADefinition()
to make sure the body comes from the current decl before rewriting it.

llvm-svn: 150325

instead of having a special-purpose function.

- ActOnCXXDirectInitializer, which was mostly duplication of
  AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
  ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
  int x = {1};
  int x({1});
  int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
   initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
  always produces a ParenListExpr. Placed that so far failed to convert that
  back to a ParenExpr containing comma operators have been fixed. I'm pretty
  sure I could have made a crashing test case before this.

The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)

This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.

llvm-svn: 150318

Drive-by fix of incorrect diagnostic, and a test case for said diagnostic. The double error is unfortunate, but I really don't see an alternative whose effort is worth it.

llvm-svn: 150317

Fix parsing new expressions using init lists. Probably still do the wrong thing in cases involving array new.
Show that many cases using initializer list constructors work, in that they parse and pass semantic analysis.

llvm-svn: 150316

a pointer cannot escape through calls to system functions. Also, stop
after reporting the first use-after-free.

llvm-svn: 150315

memory.
(As per one test case, the existing checker thought that this could
cause a lot of false positives - not sure if that's valid, to be
verified.)

llvm-svn: 150313

Resolves a common false positive, where we were reporting a leak inside
asserts

llvm-svn: 150312

We use the same logic here as the RetainRelease checker.

llvm-svn: 150311

meta-data.

llvm-svn: 150310

cv-unqualified type. This is essential in order to allow move-only objects of
const-qualified types to be copy-initialized via a converting constructor.

llvm-svn: 150309

before complaining that it's incomplete.

llvm-svn: 150308

llvm-svn: 150306

Implement warning for non-wide string literals with an unexpected encoding.  Downgrade error for non-wide character literals with an unexpected encoding to a warning for compatibility with gcc and older versions of clang.  <rdar://problem/10837678>.

llvm-svn: 150295

simplicity. Also addresses a FIXME, although not one that could be
observed.

llvm-svn: 150294

Basic support for referring to captured variables from lambdas.  Some simple examples seem to work.  Tests coming up soon.

llvm-svn: 150293

Make sure Sema creates a field for 'this' captures.  (Doug, please double-check that this is correct.)

llvm-svn: 150292

to the pattern template that it came from, otherwise we had this situation:

template <typename T1, typename T2>
struct S {
};

template <typename T>
struct S<T, int> {
};

void f() {
  S<int, int> s; // location of declaration "S<int, int>" was of "S<T1, T2>" not "S<T, int>"
}

llvm-svn: 150290

llvm-svn: 150284

default arguments if in fact those lambdas capture any entity.

llvm-svn: 150282

llvm-svn: 150281

Setting UserLabelPrefix correctly fixes PR11949.

llvm-svn: 150280

llvm-svn: 150276

llvm-svn: 150275

When creating the MCSubtargetInfo, the assembler driver uses the CPU and
feature string to construct a more accurate model of what instructions
are and are not legal.

rdar://10840476

llvm-svn: 150273