llvm-svn: 89850

llvm-svn: 89849

API change Path::isSpecialFile to Path::isRegularFile, improve semantics in regards to comments from 89765 post review.

llvm-svn: 89848

still parse the body of the switch to try to avoid spurious
diagnostics. Fixes PR5606.

llvm-svn: 89847

llvm-svn: 89846

Don't crash when we re-use a template specialization node for an explicit instantiation. lib/Support/CommandLine.cpp is our test case

llvm-svn: 89845

llvm-svn: 89844

llvm-svn: 89843

llvm-svn: 89842

llvm-svn: 89841

llvm-svn: 89840

llvm-svn: 89839

The attributes are currently ignored.

llvm-svn: 89837

llvm-svn: 89836

llvm-svn: 89835

llvm-svn: 89834

llvm-svn: 89833

statements, e.g., 

  for(; X x = X(); ) { ... }  

Daniel or Anders, please review!

llvm-svn: 89832

Add really basic support for blocks in the retain/release checker.  For now, anytime we pass a tracked object to a block call we stop tracking it.

llvm-svn: 89831

llvm-svn: 89830

llvm-svn: 89829

Split CodeTextRegion into FunctionTextRegion and BlockTextRegion.  This a precursor to having basic static analysis support for blocks.

llvm-svn: 89828

to build casted expression-list AST to Sema.

llvm-svn: 89827

using two swc/lwc instead of sdc/ldc.

llvm-svn: 89826

llvm-svn: 89824

unnecessary save/restore.

llvm-svn: 89823

llvm-svn: 89822

llvm-svn: 89821

llvm-svn: 89820

llvm-svn: 89819

llvm-svn: 89818

All statements that involve conditions can now hold on to a separate
condition declaration (a VarDecl), and will use a DeclRefExpr
referring to that VarDecl for the condition expression. ForStmts now
have such a VarDecl (I'd missed those in previous commits).

Also, since this change reworks the Action interface for
if/while/switch/for, use FullExprArg for the full expressions in those
expressions, to ensure that we're emitting

Note that we are (still) not generating the right cleanups for
condition variables in for statements. That will be a follow-on
commit.

llvm-svn: 89817

Have the parser tell sema whether a member declaration is a function definition. This allows sema to not emit spurious diagnostics in some invalid code.

llvm-svn: 89816

Make tail duplication of indirect branches much more aggressive (for targets
that indicate that it is profitable), based on further experience with
this transformation.  I compiled 3 large applications with and without
this more aggressive tail duplication and measured minimal changes in code
size.  ("size" on Darwin seems to round the text size up to the nearest
page boundary, so I can only say that any code size increase was less than
one 4k page.) Radar 7421267.

llvm-svn: 89814

This violates the ABI (that area is "reserved"), and
while it is safe if all code is generated with current
compilers, there is some very old code around that uses
that slot for something else, and breaks if it is stored
into.  Adjust testcases looking for current behavior.
I've verified that the stack frame size is right in all
testcases, whether it changed or not.  7311323.

llvm-svn: 89811

Convert test case to FileCheck to test the behavior of the nil-receiver checker when the code is targetted for either Tiger or Leopard.

llvm-svn: 89810

For the nil-receiver checker, take into account the behavioral changes that got introduced in Mac OS X 10.5 and later, notably return values of double, float, etc., will not be garbage.  Fixes <rdar://problem/6829160>.

llvm-svn: 89809

initial transition of the nil-receiver checker to the Checker
interface as done in r89745.  Some important changes include:

1) We consolidate the BugType object used for nil receiver bug
reports, and don't include the type of the returned value in the
BugType (which would be wrong if a nil receiver bug was reported more
than once)

2) Added a new (temporary) flag to CheckerContext: DoneEvauating.
This is used by GRExprEngine when evaluating message expressions to
not continue evaluating the message expression if this flag is set.
This flag is currently set by the nil receiver checker.  This is an
intermediate solution to allow the nil-receiver checker to properly
work as a plug-in outside of GRExprEngine.  Basically, this flag
indicates that the entire message expression has been evaluated, not
just a precondition (which is what the nil-receiver checker does).
This flag *should not* be repurposed for general use, but just to pull
more things out of GRExprEngine that already in there as we devise a
better interface in the Checker class.

3) Cleaned up the logic in the nil-receiver checker, making the
control-flow a lot easier to read.

llvm-svn: 89804

llvm-svn: 89803

the common routine.

llvm-svn: 89802