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

llvm-svn: 60591

llvm-svn: 60582

llvm-svn: 60581

llvm-svn: 60580

Add SymbolRef::print() and have SymbolicRegion::print() use this method instead of calling SymbolRef::getNumber().

llvm-svn: 60578

llvm-svn: 60577

Rename SymbolID to SymbolRef.  This is a precursor to some overhauling of the representation of symbolic values.

llvm-svn: 60575

llvm-svn: 60574

methods in class and its implementation.
This is work in progress.

llvm-svn: 60573

llvm-svn: 60572

StoreManager::Retrieve and StoreManager::RemoveDeadBindings now take a GRState* argument instead of a Store.  This allows them to use the GDM for storing other data.

llvm-svn: 60570

the containing block.  Introduce a new getCurFunctionOrMethodDecl
method to check to see if we're in a function or objc method.
Minor cleanups to other related places.  This fixes rdar://6405429.

llvm-svn: 60564