Implement instantiation of a few boring, simple expressions. I don't think these are testable yet, though.

llvm-svn: 71953

llvm-svn: 71907

llvm-svn: 71903

constructors and destructors. This is a requirement of
DeclarationNameTable::getCXXSpecialName that we weren't assert()'ing,
so it should have been caught much earlier :(

Big thanks to Anders for the test case.

llvm-svn: 71895

llvm-svn: 71878

llvm-svn: 71823

llvm-svn: 71800

llvm-svn: 71634

only and used in class imllementations (objc2 Nonfragile ABI specific).

llvm-svn: 71571

TemplateArgumentList. This avoids the need to pass around
pointer/length pairs of template arguments lists, and will eventually
make it easier to introduce member templates and variadic templates.

llvm-svn: 71517

specialization" within a C++ template, and permit name lookup into the
current instantiation. For example, given:

  template<typename T, typename U>
  struct X {
    typedef T type;

    X* x1;  // current instantiation
    X<T, U> *x2; // current instantiation
    X<U, T> *x3; // not current instantiation
    ::X<type, U> *x4; // current instantiation
    X<typename X<type, U>::type, U>: *x5; // current instantiation
  };

llvm-svn: 71471

llvm-svn: 71469

llvm-svn: 71409

template. The injected-class-name is either a type or a template,
depending on whether a '<' follows it. As a type, the
injected-class-name's template argument list contains its template
parameters in declaration order.

As part of this, add logic for canonicalizing declarations, and be
sure to canonicalize declarations used in template names and template
arguments. 

A TagType is dependent if the declaration it references is dependent.

I'm not happy about the rather complicated protocol needed to use
ASTContext::getTemplateSpecializationType.

llvm-svn: 71408

llvm-svn: 71405

llvm-svn: 71184

improves type identity with dependent types.

llvm-svn: 71152

llvm-svn: 71148

Back out r70506 (exception spec in AST) again. We won't have exception specs until we've had a lot more discussion.

llvm-svn: 71125

llvm-svn: 71041

block. This makes it a little easier for diagnostics generation.

llvm-svn: 71037

are ParenExpr or CastExprs.

llvm-svn: 71026

compensating for super classes). This was making the reported class
sizes for empty classes very, very wrong.
 - Also, we now report the size info for an empty class like gcc (as
   the offset of the start, not as 0, 0).

 - Add a few more test cases we were mishandling before (padding bit
   field at end of struct, for example).

llvm-svn: 70938

 - This implements gcc style Objective-C interface layout (I
   think). Currently it is always off, there is no functionality
   change unless this is passed.
   
   For the curious, the deal is that gcc lays out the fields of a
   subclass as if they were part of the superclass. That is, the
   subclass fields immediately follow the super class fields instead
   of being padded to the alignment of the superclass structure.

 - Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
   llvm-gcc uses it in 32-bit only, for reasons which aren't clear
   yet. We probably want to switch to matching gcc, once this makes it
   through testing... my hope is that we can also fix llvm-gcc in
   order to maintain compatibility between the compilers.

llvm-svn: 70827

via CollectObjCIvars.
 - In places where we need them, we should have the implementation and
   access the properties through it.

This is a fairly substantial functionality change: 
 1. @encode no longer encodes synthesized ivars, ever.

 2. The ivar layout bitmap no longer encodes information for
    synthesized ivars in superclasses. Well, actually I had already
    broken that, but it is intentional now.

We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.

Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.

I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.

llvm-svn: 70822

extension warning.

llvm-svn: 70805

llvm-svn: 70780

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

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

 - 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

into the left-hand side of an assignment expression. This completes
most of PR3500; the only remaining part is to deal with the
GCC-specific implementation-defined behavior for "unsigned long" (and
other) bit-fields.

llvm-svn: 70623

llvm-svn: 70620

expressions not yet properly handled by the CFGBuilder. This failure resulted in
a null CFGBlock* being used in rare cases (causing a crash).

llvm-svn: 70612

llvm-svn: 70586

llvm-svn: 70584

llvm-svn: 70506

"aligned" attribute. Previously, we were skipping over these
attributes when we jumped directly to the canonical type. Now,
ASTContext::getTypeInfo walks through typedefs and other
"non-canonical" types manually, looking for "aligned" attributes on
typedefs.

As part of this change, I moved the GNU-specific logic (such as
determining the alignment of void or of a function pointer) out of the
expression evaluator and into ASTContext::getTypeInfo.

llvm-svn: 70497

not supported on 32-bit targets, so we can define it to be 128-bit
aligned there too :)

llvm-svn: 70465