Flow-sensitive uninitialized values analysis: properly handle the 'element' expression of ObjCForCollectionStmt (can be anything).

llvm-svn: 59312

function call created in response to the use of operator syntax that
resolves to an overloaded operator in C++, e.g., "str1 +
str2" that resolves to std::operator+(str1, str2)". We now build a
CXXOperatorCallExpr in C++ when we pick an overloaded operator. (But
only for binary operators, where we actually implement overloading)

I decided *not* to refactor the current CallExpr to make it abstract
(with FunctionCallExpr and CXXOperatorCallExpr as derived
classes). Doing so would allow us to make CXXOperatorCallExpr a little
bit smaller, at the cost of making the argument and callee accessors
virtual. We won't know if this is going to be a win until we can parse
lots of C++ code to determine how much memory we'll save by making
this change vs. the performance penalty due to the extra virtual
calls.

llvm-svn: 59306

Don't require us to manually number the statements and expressions in StmtNodes.def. We don't need stable numbers yet, renumbering is a pain, and LAST_STMT had the wrong value anyway.

llvm-svn: 59300

llvm-svn: 59294

llvm-svn: 59290

Fix CFG construction for ObjCForCollectionStmt: 'element' expression can be anything that evaluates to an lvalue

llvm-svn: 59289

Update include files.

llvm-svn: 59284

candidates. Thanks to Chris for the review!

llvm-svn: 59260

1. In the top level of ParseStatementOrDeclaration, don't eat a } if we
   just parsed a statement if it list there.  Also, don't even bother
   emitting an error about a missing semicolon if the statement had a 
   bug (an rbrace is fine).
2. In do/while parsing, don't require a 'while' to be present if the do
   body didn't parse.

This allows us to generate a clean diagnostic for this code:

t.c:1:22: error: expected expression
void foo (void) { do . while (0); }
                     ^

Thanks to Neil for pointing this out.

llvm-svn: 59256

llvm-svn: 59255

Using llvm::OwningPtr<> for CurLexer and CurTokenLexer.  This makes both the ownership semantics of these objects explicit within the Preprocessor and also tightens up the code (explicit deletes not needed).

llvm-svn: 59249

Use PushIncludeMacroStack/PopMacroStack instead of manually pushing/popping from IncludeMacroStack.  This is both cleaner and makes the include stack transparently extensible.

llvm-svn: 59248

- Temporarily disabled test Analysis/array-struct.c for region store.

llvm-svn: 59245

llvm-svn: 59240

it to be evaluated by APSInt::operators.

llvm-svn: 59238

llvm-svn: 59235

This is required by some operations, e.g., *p = 1; p[0] = 1;.
Also set the AllocaRegion's type during the cast.

llvm-svn: 59232

type when assigning to it.

llvm-svn: 59229

llvm-svn: 59227

Correctly connect 'continue' and 'break' statements in Objective-C fast enumeration for blocks to the appropriate basic blocks.

llvm-svn: 59226

GRExprEngine/CFRefCount/GRSimpleVals: We don't do any special handling (yet) of vector types.  Add explicit checks that when we process integers that they really are scalars.

llvm-svn: 59225

some more bullet-proofing/enhancements for tryEvaluate.  This shouldn't 
cause any behavior changes except for handling cases where we were 
crashing before and being able to evaluate a few more cases in tryEvaluate.
 
This should settle the minor mess surrounding r59196.

llvm-svn: 59224

llvm-svn: 59222

the Backend output should be done in binary mode.
 - I'd appreciate it if someone who has a Windows build could verify
   this.

llvm-svn: 59221

- Don't crash on vector types.
- Handle typedefs.

llvm-svn: 59220

 - Logic such as this quite possibly should be optional builder
   behavior.

llvm-svn: 59213

little rude; I figure it's cleaner to just back this out now so 
it doesn't get forgotten or mixed up with other checkins.

The modification to isICE is simply wrong; I've added a test that the 
change to isICE breaks.

I'm pretty sure the modification to tryEvaluate is also wrong.  
At the very least, there's some serious miscommunication going on here, 
as this is going in exactly the opposite direction of r59105.  My 
understanding is that tryEvaluate is not supposed to care about side 
effects.  That said, a lot of the clients to tryEvaluate are 
expecting it to enforce a no-side-effects policy, so we probably need 
another method that provides that guarantee.

llvm-svn: 59212

landing pads.
 - Primarily a cleanliness issue instead of a performance issue (this
   eliminates all blocks w/o predecessors on 176.gcc/expr.c), but this
   also allows subsequent code to recognize it is unreachable and
   potentially avoid IRgen.

llvm-svn: 59211

 - Use dotted notation for blocks related to a particular statement
   type.
 - Use .end for landing pads.

No functionality change in NDEBUG mode. :)

llvm-svn: 59210

 - Indicates that caller is done with the block and it can be dropped
   if it has no predecessors. Useful for callers who need to make
   landing pads but which may not be reached.

No functionality change.

llvm-svn: 59207

more confusing ifelse.

Use dotted names for if blocks (if.then vs ifthen).

llvm-svn: 59201

Fix bug where the body block of an ObjCForCollectionStmt would not properly get expanded as a series of basic blocks.

llvm-svn: 59197

 - Evaluation of , operator used bogus assumption that LHS could be
   evaluated as an integral expression even though its type is
   unspecified.

This change is making isICE very permissive of the LHS in non-evaluated 
contexts because it is not clear what predicate we would use to reject 
code here. The standard didn't offer me any guidance; opinions?

llvm-svn: 59196

conversion functions. Instead, we just use a placeholder identifier
for these (e.g., "<constructor>") and override NamedDecl::getName() to
provide a human-readable name.

This is one potential solution to the problem; another solution would
be to replace the use of IdentifierInfo* in NamedDecl with a different
class that deals with identifiers better. I'm also prototyping that to
see how it compares, but this commit is better than what we had
previously.

llvm-svn: 59193

llvm-svn: 59191

llvm-svn: 59188

llvm-svn: 59186

PreprocessorLexer now has a virtual method "IndirectLex" which allows it to call the lex method of its subclasses.  This is not for performance intensive operations.

llvm-svn: 59185

something that is not an int.

 - Ignore these cases for now, added FIXME that we should also boolize
   them.

llvm-svn: 59184

llvm-svn: 59181