llvm-svn: 60791

llvm-svn: 60790

In GRExprEngine treat @throw as an 'abort' that ends the current path.  This is a temporary solution.

llvm-svn: 60789

llvm-svn: 60782

Sema::ActOnMethodDeclaration(): Make sure we perform the default function/array conversion for parameter types.

This fixes <rdar://problem/6424064> checker on xcode: (possible bad AST) can the type of a method parameter really have "isFunctionType() == true"?
and http://llvm.org/bugs/show_bug.cgi?id=2997.

llvm-svn: 60781

llvm-svn: 60778

llvm-svn: 60761

llvm-svn: 60758

llvm-svn: 60734

Fixed LiveVariables bug where we didn't consider block-level expressions that functioned as the size of a VLA to be live.

llvm-svn: 60730

llvm-svn: 60729

llvm-svn: 60726

This is important because ParseDeclarationOrFunctionDefinition
skips to, but does not consume, an } on error.

llvm-svn: 60719

llvm-svn: 60718

'self.myIvar = nil' (properties) only releases myIvar when the property has kind 'assign'.  This fixes <rdar://problem/6380411>.

llvm-svn: 60717

Fixes <rdar://problem/6418640> clang on prokit: error: incompatible type returning 'id', expected 'NSSize'

llvm-svn: 60716

warning as it is allowed in gcc and will break projects.

llvm-svn: 60710

must allow the continuation class to extend it to a 'readwrite'
and 'copy/retain'.

llvm-svn: 60709

llvm-svn: 60708

llvm-svn: 60693

llvm-svn: 60686

code were working correctly, it would be a no-op, but it's not really a 
proper fix.  That said, I don't really want to touch the enum code at 
the moment because I don't understand it very well, and this seems to 
be a relatively visible regression.

llvm-svn: 60680

llvm-svn: 60655

llvm-svn: 60645

llvm-svn: 60638

Bug reported by Chris L.

llvm-svn: 60635

via the category's protocol list1s, with appropriate
diagnsostics and a test case.

llvm-svn: 60634

type mimatches.

llvm-svn: 60630

llvm-svn: 60629

llvm-svn: 60628

llvm-svn: 60626

testing declaration of properties in categories.

llvm-svn: 60625

llvm-svn: 60622

attributes. Example would be, readonly, assign or
assign, copy, etc.

llvm-svn: 60620

  template<typename T> void f(T x) {
    g(x); // g is a dependent name, so don't even bother to look it up
    g(); // error: g is not a dependent name
  }

Note that when we see "g(", we build a CXXDependentNameExpr. However,
if none of the call arguments are type-dependent, we will force the
resolution of the name "g" and replace the CXXDependentNameExpr with
its result.

GCC actually produces a nice error message when you make this
mistake, and even offers to compile your code with -fpermissive. I'll
do the former next, but I don't plan to do the latter.

llvm-svn: 60618

expressions, and value-dependent expressions. This permits us to parse
some template definitions.

This is not a complete solution; we're missing type- and
value-dependent computations for most of the expression types, and
we're missing checks for dependent types and type-dependent
expressions throughout Sema.

llvm-svn: 60615

llvm-svn: 60611

property. It also checks for duplicate use of the same ivar
in two different iproperty implementations. It also caught
an error for a test case used in CodeGen :).

llvm-svn: 60610

(instance/class) Method type checking between category and its implementation.
And a test case for all.

llvm-svn: 60598

parameters, with some semantic analysis:
  - Template parameters are introduced into template parameter scope
  - Complain about template parameter shadowing (except in Microsoft mode)

Note that we leak template parameter declarations like crazy, a
problem we'll remedy once we actually create proper declarations for
templates. 

Next up: dependent types and value-dependent/type-dependent
expressions.

llvm-svn: 60597