unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies LLVM_INCLUDE_X

llvm-svn: 114747

llvm-svn: 114746

llvm-svn: 114745

http://google1.osuosl.org:8011/builders/llvm-gcc-i386-linux-selfhost

gets happy.

llvm-svn: 114742

Fixed //rdar://8472487.

llvm-svn: 114741

llvm-svn: 114739

vla. Implements pr7827.

llvm-svn: 114737

llvm-svn: 114736

llvm-svn: 114735

llvm-svn: 114733

llvm-svn: 114728

llvm-svn: 114727

llvm-svn: 114726

llvm-svn: 114725

llvm-svn: 114724

llvm-svn: 114723

interface in ClangASTContext. Also added two bool returning functions that
indicated if an opaque clang qual type is a CXX class type, and if it is an
ObjC class type.

Objective C classes now will get their methods added lazily as they are
encountered. The reason for this is currently, unlike C++, the 
DW_TAG_structure_type and owns the ivars, doesn't not also contain the
member functions. This means when we parse the objective C class interface
we either need to find all functions whose names start with "+[CLASS_NAME"
or "-[CLASS_NAME" and add them all to the class, or when we parse each objective
C function, we slowly add it to the class interface definition. Since objective
C's class doesn't change internal bits according to whether it has certain types
of member functions (like C++ does if it has virtual functions, or if it has
user ctors/dtors), I currently chose to lazily populate the class when each
functions is parsed. Another issue we run into with ObjC method declarations
is the "self" and "_cmd" implicit args are not marked as artificial in the
DWARF (DW_AT_artifical), so we currently have to look for the parameters by
name if we are trying to omit artificial function args if the language of the
compile unit is ObjC or ObjC++.

llvm-svn: 114722

Remove this test for now until I figure out how to get it to work with c-index-test in a portable way.

llvm-svn: 114721

llvm-svn: 114720

 - I believe more modern 'gas' supports a more enhanced set of arithmetic on
   them, but for now the only thing we can do is emit them as data.

llvm-svn: 114719

llvm-svn: 114718

llvm-svn: 114717

Since this test depends on default ivar synthesis, specify the target triple.  This hopefully unbreaks the buildbot
on some archs.

llvm-svn: 114716

llvm-svn: 114715

Default synthesized ivars don't really have a location in the source.  Using the location of the @implementation
is just confusing for clients that want to use SourceLocations for syntactic references.

Fixes: <rdar://problem/8470540>
llvm-svn: 114714

llvm-svn: 114713

llvm-svn: 114712

llvm-svn: 114711

reflection, this isn't going to achieve the purpose I intended it for.  Back to the drawing board!

llvm-svn: 114710

llvm-svn: 114709

testing various combinations of displaying variales of basic types.

The generic_type_tester() works by first capturing the golden output produced
by the printf stmts of ./a.out, creating a list of (var, value) pairs, and then
running the a.out to a stop point, and comparing the 'frame variable var' output
against the list of (var, value) pairs.

Modified int_type() and added long_type() to use generic_type_tester().

Also modified TestBase.expect() such that substring matching also return ok if
the substring starts at the 0-th position.

llvm-svn: 114708

llvm-svn: 114707

llvm-svn: 114706

llvm-svn: 114705

provided when the optimization is disabled. In particular, split
the completion context CCC_Other into two contexts: CCC_Other, which
means that it's an undisclosed context for which any other results are
unwelcome, and CCC_Recovery, which is used in recovery cases.

Since we're now using the completion context within the completion
results builder, make sure that it's always set to something.

Fixes <rdar://problem/8470644>.

llvm-svn: 114704

llvm-svn: 114703

Not intended functionality change, as nothing uses this yet.

llvm-svn: 114702

llvm-svn: 114701

llvm-svn: 114697

llvm-svn: 114696