llvm-svn: 70786

llvm-svn: 70785

in C++. Fixes <rdar://problem/6815995>.

llvm-svn: 70784

llvm-svn: 70783

printing. Also, when we only need to truncate the line at the end,
make sure there is room for the ellipsis.

llvm-svn: 70781

llvm-svn: 70780

just computing it!

llvm-svn: 70779

llvm-svn: 70778

llvm-svn: 70777

llvm-svn: 70776

Lift up a size calculation and note some asymmetries.

llvm-svn: 70775

llvm-svn: 70774

llvm-svn: 70773

llvm-svn: 70771

struct.
 - We still need to do more lookup than necessary because ivars don't
   live in a reasonable DeclContext.

 - The only remaining client of the interface shadow struct is the
   ivar layout bitmap.

llvm-svn: 70756

decl. Only this routine will be suitable for computing the offset of a
synthesized ivar.
 - No functionality change.

llvm-svn: 70696

invalidated by layout out the super class, we cannot cache the map
entry.

llvm-svn: 70693

 - These routines should now be independent of the Sema state.

 - This is nearly zero functionality change, the distinction only
   matters in the non-fragile ABI, and the consumers that care about
   this distinction should be using getASTObjCImplementationLayout.

llvm-svn: 70692

not the shadow structure.

llvm-svn: 70691

 - The difference from getASTObjCInterfaceLayout is that the computes
   the layout including synthesized ivars.

 - No functionality change, they currently both compute the same thing
   -- whether that includes synthesized ivars or not depends on when
   they get called!!!

llvm-svn: 70690

llvm-svn: 70689

this fixes http://llvm.org/bugs/show_bug.cgi?id=3373#c20

llvm-svn: 70685

llvm-svn: 70684

llvm-svn: 70683

llvm-svn: 70681

llvm-svn: 70680

from the asm string, but reject references to the smaller one.

llvm-svn: 70679

llvm-svn: 70678

the input.  This is part of PR3373.

llvm-svn: 70677

like bitfields.  incidentally llvm-gcc crashes on this sort of thing also. :)

llvm-svn: 70675

 - No functionality change.

llvm-svn: 70674

llvm-svn: 70673

llvm-svn: 70672

processing the outputs, no functionality change.

llvm-svn: 70671

number is not mentioned in the asm string, let it past sema. 
Right now these are currently rejected by the llvm code generator
but this will be fixed next.

llvm-svn: 70670

promotions.  This should be fixed by not modeling asm operands (which 
require the ()'s according to the grammar) as not being paren exprs.

llvm-svn: 70668

Fix: <rdar://problem/6850275> CF objects returned from methods with "new" or "copy" in their name should be treated as owned

For methods that follow the "fundamental rule" and return Core
Foundation objects, treat those objects as owned by the caller.

llvm-svn: 70665

llvm-svn: 70664

llvm-svn: 70663

no functionality change.

llvm-svn: 70662