Enhance dead store checker to not flag preincrements to dead variables where the preincrement is a subexpression, e.g. foo(++x);  This can cause false negatives, but will remove a whole class of false positives.

llvm-svn: 57554

llvm-svn: 57540

Note: One day, we should consider moving the actual diags to ObjCQualifiedIdTypesAreCompatible(), since it has more information on the actual problem. GCC currently emits slightly more instructive errors for some cases involving protocols. I added a FIXME to the code.

llvm-svn: 57529

llvm-svn: 57499

llvm-svn: 57479

 - Follows the MSVC (original) implementation, including support of
   pack(show) (useful for testing).
 - Implements support for named pack records which gcc seems to
   ignore (or implements incorrectly).
 - Not currently wired to anything, only functionality change is the
   type checking of the pragma.

llvm-svn: 57476

Rename -dumptokens to -dump-tokens.

llvm-svn: 57405

llvm-svn: 57341

class C {
  static const int number = 50;
  static int arr[number];
};

Here's how it worked:
-GetTypeForDeclarator was called from both Sema::ActOnCXXMemberDeclarator and Sema::ActOnDeclarator.
-VariableArrayTypes are not uniqued so two VariableArrayTypes were created with the same DeclRefExpr.
-On exit they both tried to destroy that one DeclRefExpr.

The fix is not to use GetTypeForDeclarator from the Sema::ActOnCXXMemberDeclarator.

llvm-svn: 57313

In ParseParenDeclarator match "D.setGroupingParens(true);" with another setGroupingParens call after the ')' is parsed.
Fixes this bug:
  int (x)(0); // error, expected function declarator where the '(0)' initializer is

llvm-svn: 57241

This is how this kind of initializers appear in the AST:
-The Init expression of the VarDecl is a functional type construction (of the VarDecl's type).
-The new VarDecl::hasCXXDirectInitializer() returns true.

e.g, for "int x(1);":
-VarDecl 'x' has Init with expression "int(1)" (CXXFunctionalCastExpr).
-hasCXXDirectInitializer() of VarDecl 'x' returns true.

A major benefit is that clients that don't particularly care about which exactly form was the initializer can handle both cases without special case code.
Note that codegening works now for "int x(1);" without any changes to CodeGen.

llvm-svn: 57178

llvm-svn: 57165

won't expand to the builtin.  This fixes rdar://6248329

llvm-svn: 57164

constant lvalue.  Implement this in codegen by moving the code out of CGBuiltin
into EmitConstantExpr.

llvm-svn: 57163

condition as a constant even if the unevaluated side is a not a constant.
We don't do this when extensions are off, and we emit a warning when this 
happens:

t.c:22:11: warning: expression is not a constant, but is accepted as one by GNU extensions
short t = __builtin_constant_p(5353) ? 42 : somefunc();
          ^                                 ~~~~~~~~~~

suggestions for improvement are welcome.  This is obviously horrible, but
is required for real-world code.

llvm-svn: 57153

llvm-svn: 57143

No funcitonality change.

llvm-svn: 57136

sizeof(int()) -> "int()" is type-id
sizeof(int()+1) -> "int()+1" is expression.

llvm-svn: 57131

Found a subtle bug caused by an implicit enum-to-bool conversion (of the TentativeParsingResult enum).
This was the motivation of the following changes:

-'TentativeParsingResult' enum is replaced by a 'TPResult' class that basically encapsulates the enum.
-TPR_true, TPR_false, TPR_ambiguous, and TPR_error enum constants are replaced by TPResult::True(), TPResult::False(), etc. calls that return a TPResult object.
-Also fixed the subtle bug in Parser::isCXXFunctionDeclarator (caught by the above changes as a compilation error).

llvm-svn: 57125

llvm-svn: 57121

Disambiguate between a declaration or an expression, in the 'for-init-statement' part of a 'for' statement.

llvm-svn: 57112

llvm-svn: 57111

Disambiguate between a declaration or expression for the 'condition' part of a if/switch/while/for statement.

llvm-svn: 57109

llvm-svn: 57108

llvm-svn: 57104

llvm-svn: 57103

llvm-svn: 57101

llvm-svn: 57094

 - This pushes us over 80% coverage of executable LOC.

llvm-svn: 57092

 - Hit debug info generation.
 - Hit both ObjC runtimes.

llvm-svn: 57088

llvm-svn: 57085

'ParseTentative.cpp' implements the functionality needed to resolve ambiguous C++ statements, to either a declaration or an expression, by "tentatively parsing" them.

llvm-svn: 57084

 - AST printing, dumping, serialization, codegen.
 - HTML printing.
 - Parser callbacks.

Several of these are XFAIL because they trigger unimplemented code.

llvm-svn: 57081

 - It would probably be better if TestRunner.sh canonicalized this.

llvm-svn: 57075

llvm-svn: 57072

 - env-include-paths.c is XFAIL as it exposed a bug.

Add test/Coverage.
 - For tests which achieve code coverage but don't validate anything.

llvm-svn: 57070

llvm-svn: 57069

llvm-svn: 57068

up.  Speculatularly hacktastic, but strangely beautiful?
Daniel, lines 20/21 are rejected, please investigate.

llvm-svn: 57067

 - Uses Action::ActOnPragmaPack
 - Test case is XFAIL pending verifier fixes.

llvm-svn: 57066