llvm-svn: 65335

of a pointer to object; This patch does this odd behavior according to
gcc.

llvm-svn: 65334

- Generate error for protocol qualifiers on non-ObjC types.

llvm-svn: 65333

Remove support for "Class<P>". Will be making this an error.

llvm-svn: 65332

llvm-svn: 65331

This doesn't change the current functionality, but better codifies the
autorelease pool stack itself.

llvm-svn: 65328

 - No functionality change.

llvm-svn: 65325

llvm-svn: 65322

Per Chris L.'s suggestion, use getAsFunctionType() instead of getDesguaredType().  Constify some pointers along the way.

llvm-svn: 65321

I don't think casting super makes any sense (since it won't effect method lookup).
Will discuss with other offline and decide what to do.

llvm-svn: 65317

llvm-svn: 65305

retain/release checker: For now don't track the retain count of NSWindow objects (opt for false negatives).

llvm-svn: 65304

llvm-svn: 65303

llvm-svn: 65302

llvm-svn: 65301

Sema::ActOnInstanceMessage(): Tighen up the lookup rules for handling messages to 'Class'. Also improve "super" handling.

llvm-svn: 65300

llvm-svn: 65299

llvm-svn: 65293

Contains the following (related to problems found while investigting <rdar://problem/6497631> Message lookup is sometimes different than gcc's).

- Implement instance/class overloading in ObjCContainerDecl (removing a FIXME). This involved hacking NamedDecl::declarationReplaces(), which took awhile to figure out (didn't realize replace was the default).
- Changed Sema::ActOnInstanceMessage() to remove redundant warnings when dealing with protocols. For now, I've omitted the "protocol" term in the diagnostic. It simplifies the code flow and wan't always 100% accurate (e.g. "Foo<Prot>" looks in the class interface, not just the protocol).
- Changed several test cases to jive with the above changes.

llvm-svn: 65292

Make sure to reset the DidCallStackSave variable before emitting a compound statement. Fixes PR3649.

llvm-svn: 65291

true a local pointer to objective-c object in generating
write barriers.

llvm-svn: 65290

llvm-svn: 65286

llvm-svn: 65285

someone would reasonably expect Evaluate to handle for C/ObjC.

llvm-svn: 65284

llvm-svn: 65283

llvm-svn: 65281

llvm-svn: 65280

memory using Indirect; this was a holdover from when CGCall wasn't as
robust.

llvm-svn: 65278

llvm-svn: 65276

llvm-svn: 65270

Fix regression in naming convention derivation: a method only follows the copy 'rule' if it doesn't already start with 'init', etc.

llvm-svn: 65269

llvm-svn: 65267

as byval. Otherwise LLVM will have its own opinion about where to put
things.

We now pass all gcc dg.compat tests on x86_64.

llvm-svn: 65266

helper isConstantInitializer) to check whether an initializer is 
constant.  This passes tests, but it's possible that it'll cause 
regressions with real-world code.

Future work:
1. The diagnostics obtained this way are lower quality at the moment; 
some work both here and in Evaluate is needed for accurate diagnostics.
2. We probably need some extra code when we're in -pedantic mode so we 
can strictly enforce the rules in C99 6.6p7.
3. Dead code cleanup (this should wait until after 2, because we might 
want to re-use some of the code).

llvm-svn: 65265

about these much but <2 x i16> shows up in the gcc test suite.

llvm-svn: 65264

of sizes. Turns out we don't care very much about vector types that
don't map to the hardware.

llvm-svn: 65263

Also, make sure to pass <1 x i64> as i64 (not <1 x i64>, which doesn't
quite work yet in the backend).

llvm-svn: 65262

I know, these follow the exact same rules as pointers, so I just made 
them use the same codepath.  Someone more familiar with ObjC should 
double-check this, though.

llvm-svn: 65261

partially done in r65258.)

llvm-svn: 65260

CodeGen.  I'm not sure whether this actually makes any visible 
difference, but it's better to be consistent anyway.

llvm-svn: 65259