llvm-svn: 112005

objc-nonfragile-abi2 (radar 7824380).

llvm-svn: 111823

methods.

llvm-svn: 111804

llvm-svn: 111768

it deserves its own enumerator.  Obviously the implementations should
closely follow the Itanium ABI except in cases of divergence.

llvm-svn: 111749

Fix an issue with writing to PCH another included PCH, introduced by the "using an AST on-disk hash table for name lookup" commit.

When including a PCH and later re-emitting to another PCH, the name lookup tables of DeclContexts
may be incomplete, since we now lazily deserialize the visible decls of a particular name.
Fix the issue by iterating over the un-deserialized visible decls and completing the lookup tables
of DeclContexts before writing them out.

llvm-svn: 111698

over ivars for a varienty of puposes is now
consolidated into two small routines; DeepCollectObjCIvars
and ShallowCollectObjCIvars. 

llvm-svn: 111679

*Huge* improvement over the amount of deserializing that we do for C++ lookup.
e.g, if he have the Carbon header precompiled and include it on a file containing this:

int x;

these are the before/after stats:

BEFORE:

*** AST File Statistics:
  578 stat cache hits
  4 stat cache misses
  548/30654 source location entries read (1.787695%)
  15907/16501 types read (96.400223%)
  53525/59955 declarations read (89.275291%)
  33993/43525 identifiers read (78.099945%)
  41516/51891 statements read (80.006165%)
  77/5317 macros read (1.448185%)
  0/6335 lexical declcontexts read (0.000000%)
  1/5424 visible declcontexts read (0.018437%)

AFTER using the on-disk table:

*** AST File Statistics:
  578 stat cache hits
  4 stat cache misses
  548/30654 source location entries read (1.787695%)
  10/16501 types read (0.060602%)
  9/59955 declarations read (0.015011%)
  161/43525 identifiers read (0.369902%)
  20/51891 statements read (0.038542%)
  6/5317 macros read (0.112846%)
  0/6335 lexical declcontexts read (0.000000%)
  2/5424 visible declcontexts read (0.036873%)

There's only one issue affecting mostly the precompiled preambles which I will address soon.

llvm-svn: 111636

llvm-svn: 111584

for incomplete enum types.  An incomplete enum can't really be treated as
an "integral or enumeration" type, and the incorrect treatment leads to
bad behavior for many callers.

This makes isIntegralOrEnumerationType equivalent to isIntegerType; I think
we should globally replace the latter with the former; thoughts?

llvm-svn: 111512

active C++ ABI as a raw string, we store it as an enum. This should improve
performance somewhat.

And yes, this time, I started from a clean build directory, and
all the tests passed. :)

llvm-svn: 111507

llvm-svn: 111498

All it does right now is add space for two vtable pointers instead of one
when a class has both virtual methods and virtual bases. This is a requirement
of the Microsoft ABI, since it has separate vtables for methods and bases. Other
stuff will come up over time, but we'll cross those bridges when we get to
them.

llvm-svn: 111493

Now all classes derived from Attr are generated from TableGen.
Additionally, Attr* is no longer its own linked list; SmallVectors or
Attr* are used. The accompanying LLVM commit contains the updates to
TableGen necessary for this.

Some other notes about newly-generated attribute classes:

 - The constructor arguments are a SourceLocation and a Context&,
   followed by the attributes arguments in the order that they were
   defined in Attr.td

 - Every argument in Attr.td has an appropriate accessor named getFoo,
   and there are sometimes a few extra ones (such as to get the length
   of a variadic argument).

Additionally, specific_attr_iterator has been introduced, which will
iterate over an AttrVec, but only over attributes of a certain type. It
can be accessed through either Decl::specific_attr_begin/end or
the global functions of the same name.

llvm-svn: 111455

than GCC 4.2 here when building 32-bit (where GCC will allow
allocation of an array for which we can't get a valid past-the-end
pointer), and emulate its odd behavior in 64-bit where it only allows
63 bits worth of storage in the array. The former is a correctness
issue; the latter is harmless in practice (you wouldn't be able to use
such an array anyway) and helps us pass a GCC DejaGNU test.

Fixes <rdar://problem/8212293>.

llvm-svn: 111338

llvm-svn: 111314

Radar 8308053.

llvm-svn: 111275

llvm-svn: 111238

and remove getStrData().  Patch by Peter Davies (with some tweaks).

llvm-svn: 111229

no functionality change.

llvm-svn: 111207

AST library.

This also adds infrastructure for supporting multiple C++ ABIs in the AST.

llvm-svn: 111117

llvm-svn: 111110

llvm-svn: 111101

llvm-svn: 111091

llvm-svn: 111089

llvm-svn: 111088

llvm-svn: 111087

Unused warnings for functions:
-static functions
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace

Unused warnings for variables:
-static variables
-variables in anonymous namespace
-static data members in anonymous namespace
-static data members specializations in anonymous namespace

Reveals lots of opportunities for dead code removal in llvm codebase that will
interest my esteemed colleagues.

llvm-svn: 111086

llvm-svn: 111080

instantiated with unique-external parameters.

llvm-svn: 111012

llvm-svn: 110996

llvm-svn: 110950

llvm-svn: 110912

Remove OwnershipAttr::Kind, since it's essentially redundant with attr::Kind the way it's being used. Also fix isa<OwnershipAttr> support, break more-than-80-char lines, and other miscellaneous ownership attr cleanup.

llvm-svn: 110908

llvm-svn: 110860

llvm-svn: 110840

and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
breakage.

llvm-svn: 110803

"editing" mode, introduce a separate function
clang_defaultEditingTranslationUnitOptions() that retrieves the set of
options. No functionality change.

llvm-svn: 110613

- Make ObjCInterfaceDecl redeclarable, and create separate decl nodes for forward declarations and the definition.
- Eagerly create ObjCInterfaceTypes for declarations.
- The two above changes lead to a 0.5% increase in memory use and no speed regression when parsing Cocoa.h. On the other hand, now chained PCH works when there's a forward declaration in one PCH and the interface definition in another.
- Add HandleInterestingDecl to ASTConsumer. PCHReader passes the "interesting" decls it finds to this function instead of HandleTopLevelDecl. The default implementation forwards to HandleTopLevelDecl, but ASTUnit's handler for example ignores them. This fixes a potential crash when lazy loading of PCH data would cause ASTUnit's "top level" declaration collection to change while being iterated.

llvm-svn: 110610

llvm-svn: 110609