llvm-svn: 57907

Found this while fixing another unrelated radar.

llvm-svn: 57904

llvm-svn: 57903

llvm-svn: 57902

Tweak an expected-error to match the output. IMHO it is better to diagnose 'int (void)' because it has the same meaning in C and C++.

llvm-svn: 57901

llvm-svn: 57899

Fix <rdar://problem/6265257> warnings for ambiguous message send swamp other warnings.

Reworked Sema::MatchTwoMethodDeclarations() to optionally match based on method size and alignment (the default in GCC). Changed Sema::LookupInstanceMethodInGlobalPool() to use this feature.

Added -Wno-struct-selector-match to driver, however didn't hook it up yet. Added a FIXME that says this.

llvm-svn: 57898

GRExprEngine::VisitCast() so that other parts of the analyzer can be ignorant.
When we cast "array of type T" to "pointer to T", we get the loc::MemRegionVal
corresponding to the array variable. This is sufficient for BasicStore, but not
for RegionStore. RegionStore should get the element region for the first array
element in the cast. So next comes to the revamping of transfer functions for
different store model.

llvm-svn: 57897

llvm-svn: 57896

llvm-svn: 57895

  RValues.h/cpp => SVals.h/cpp

llvm-svn: 57893

initialized to UndefinedVal.

llvm-svn: 57892

llvm-svn: 57891

llvm-svn: 57890

llvm-svn: 57878

llvm-svn: 57877

llvm-svn: 57876

llvm-svn: 57863

Further improve path-sensitivity with divide-by-zero checking by assuming that a denominator cannot be zero even when the result of an '/' or '%' expression is unknown.

llvm-svn: 57855

Added test case inspired by <rdar://6268365>: recover path-sensitivity after compound assignment when the result of the assignment is not known.

llvm-svn: 57852

Used conjured symbols to recover path-sensitivity when the result of a compound assignment is UnknownVal().

llvm-svn: 57851

llvm-svn: 57850

Sema::CheckCompareOperands() and ASTContext::mergeTypes(): Change handling of ObjC qualified id types to be consistent with gcc. This changes a handful of test case errors into warnings (diff will tell you which cases have changed).

llvm-svn: 57841

llvm-svn: 57818

strcmp when needed.

llvm-svn: 57817

llvm-svn: 57816

llvm-svn: 57815

llvm-svn: 57814

llvm-svn: 57813

weird errors about property attributes being unknown.

llvm-svn: 57812

crash.m:8:12: error: type name requires a specifier or qualifier
@property (readonlyx, getter=isAwesome) int _awesome;
           ^
crash.m:8:29: error: expected ';' at end of declaration list
@property (readonlyx, getter=isAwesome) int _awesome;
                            ^
crash.m:8:39: error: expected identifier or '('
@property (readonlyx, getter=isAwesome) int _awesome;
                                      ^

we now get:

crash.m:8:12: error: unknown property attribute 'readonlyx'
@property (readonlyx, getter=isAwesome) int _awesome;
           ^

Also, we can eliminate isObjCPropertyAttribute now.

llvm-svn: 57811

llvm-svn: 57810

ParseObjCPropertyAttribute.  Before, on this code (where
a comma was forgotten):

@property (readonly getter=isAwesome) int _awesome;

we emitted:

crash.m:9:11: error: expected ')'
@property (readonly getter=isAwesome) int _awesome;
          ^
crash.m:9:37: error: type name requires a specifier or qualifier
@property (readonly getter=isAwesome) int _awesome;
                                    ^
crash.m:9:37: error: expected identifier or '('
crash.m:9:37: error: expected ';' at end of declaration list
crash.m:9:1: error: @property requires fields to be named
@property (readonly getter=isAwesome) int _awesome;
^

now we emit:

crash.m:9:21: error: expected ')'
@property (readonly getter=isAwesome) int _awesome;
                    ^
crash.m:9:11: error: to match this '('
@property (readonly getter=isAwesome) int _awesome;
          ^

llvm-svn: 57809

llvm-svn: 57808

llvm-svn: 57807

llvm-svn: 57806

@property (readonly) int : 4;

llvm-svn: 57805

occurs, skip to an @ or ; instead of to a } or ;.  Properties
don't necessarily live in {}'s.

llvm-svn: 57804

Check for @end in ParseObjCInterfaceDeclList instead of in each caller
Handle @required and @optional with the same code

Add some fixmes about some apparently objc2 code that is being accepted
in objc1.

llvm-svn: 57803

where it would reject @required in non-protocols, but then go
ahead and tag methods with required anyway.  Instead, if we see
this in something other than a protocol, just ignore the request.

Also, improve error recovery a bit when we see something bogus 
inside an interface.

llvm-svn: 57798