Fix PR 9626 (duplicated self-init warnings under -Wuninitialized) with numerous CFG and UninitializedValues analysis changes:

1) Change the CFG to include the DeclStmt for conditional variables, instead of using the condition itself as a faux DeclStmt.
2) Update ExprEngine (the static analyzer) to understand (1), so not to regress.
3) Update UninitializedValues.cpp to initialize all tracked variables to Uninitialized at the start of the function/method.
4) Only use the SelfReferenceChecker (SemaDecl.cpp) on global variables, leaving the dataflow analysis to handle other cases.

The combination of (1) and (3) allows the dataflow-based -Wuninitialized to find self-init problems when the initializer
contained control-flow.

llvm-svn: 128858

llvm-svn: 128857

llvm-svn: 128855

llvm-svn: 128854

llvm-svn: 128853

between libFrontend and libDriver.

llvm-svn: 128852

llvm-svn: 128850

Introduce Driver::createInvocationFromArgs used to create a CompilerInvocation from command-line args.

llvm-svn: 128848

-Wuninitialized: use "self-init" warning when issue uninitialized values warnings from the dataflow analysis that include within the initializer of a variable.

llvm-svn: 128843

llvm-svn: 128842

llvm-svn: 128840

-Wuninitialized: don't issue fixit for initializer if a variable declaration already has an initializer.

llvm-svn: 128838

When emitting a "too many arguments to function call..." error, also include a note with a location for the function prototype.

llvm-svn: 128833

Sandeep Patel noticed that the alignment was wrong for Neon vector types,
and this change is partly derived from his patch.  For the APCS ABI, however,
additional changes were required: the maximum ABI alignment is 32 bits and
the preferred alignment for i64 and f64 types should be 64 bits.

llvm-svn: 128825

I'm pretty sure this is the right fix, but I would appreciate it if someone
else would double-check.

llvm-svn: 128806

Refactoring the security checker a little bit so that each CallExpr check doesn't get called for each CallExpr. Instead it does a switch and only runs the check for the proper identifier. Slight speed improvement (probably significant on very large ASTs), and should make it easier and more clear to add more checks for other CallExpr's later.

llvm-svn: 128785

static analyzer: Add a new ProgramPoint PostCondition to represent the post position of a branch condition, and a new generateNode method to BranchNodeBuilder using PostCondition ProgramPoint. This method generates a new ExplodedNode but not a new block edge.

Patch by Lei Zhang!

llvm-svn: 128784

Fix RegionStore bug when doing a field load whose parent is also a field assigned a LazyCompoundValue.  Fixes <rdar://problem/9163742> and PR 9522.

llvm-svn: 128783

llvm-svn: 128780

CharUnits. No change in functionality intended.

llvm-svn: 128776

change in functionality intended.

llvm-svn: 128773

dumpLayout(). No change in functionality intended.

llvm-svn: 128771

change in functionality intended.

llvm-svn: 128770

a couple of operator overloads which form interesting expressions in the
AST.

I added test cases for both bugs with the c-index-test's token
annotation feature. Also, thanks to John McCall for confirming that this
is the correct solution.

llvm-svn: 128768

llvm-svn: 128762

Teach IdempotentOperationsChecker about paths aborted because ExprEngine didn't know how to handle a specific Expr type.

llvm-svn: 128761

static analyzer: Rename 'BlocksAborted' to 'BlocksExhausted' to reflect that a given CFGBlock was analyzed too many times.

llvm-svn: 128760

functionality intended.

llvm-svn: 128756

CharUnits. No change in functionality intended.

llvm-svn: 128754

functionality intended.

llvm-svn: 128753

No change in functionality intended.

llvm-svn: 128752

block pointer nested inside a block. // rdar:// 9204669

llvm-svn: 128747

llvm-svn: 128738

__byref block. // rdar://9204669

llvm-svn: 128726

llvm-svn: 128725

location into a TemplateSpecializationTypeLoc. These were found using
a hand-written program to inspect every source location in
TemplateSpecializationTypeLocs and Valgrind. I don't know of any way to
test them in Clang's existing test suite sadly.

Example code that triggers the ElaboratedType case:
  template <typename T> struct X1 {
    template <typename U> struct X1_1 {
      int x;
    };
  };

  template <typename T, typename U> struct X2 {
    typename X1<T>::template X1_1<U> B;
  };

  X2<char, int> x2;

The other fix was simply spotted by inspection. I audited all constructions of
[Dependent]TemplateSpecializationTypeLocs in TreeTransform.h, and the rest set
the TemplateNameLoc properly.

llvm-svn: 128702

that of the array element type.

llvm-svn: 128698

arrays by propagating", it's breaking test in ways I don't understand yet.

llvm-svn: 128693

the array alignment to the array access.
 - This is more or less the best we can do without having alignment present in
   the type system, but is a long way from truly matching how GCC handles this.

llvm-svn: 128691

__block block declaration. //rdar://9204669

llvm-svn: 128682