llvm-svn: 153721

ConstStructBuilder: fix offset math for base classes so it works correctly in general.  Found by inspection.

llvm-svn: 153720

ValueObject, and make sure that ValueObjects that
have null type names (because they have null types)
also have null qualified type names.  This avoids
some potential crashes if 
ValueObject::GetQualifiedTypeName tries to get the
name of their type by calling GetClangTypeImpl().

llvm-svn: 153718

ARM target should allow codegenprep to duplicate ret instructions to enable tailcall opt. rdar://11140249

llvm-svn: 153717

Make sure we perform the relevant implied conversions correctly for ObjC methods with related result types. PR12384.

llvm-svn: 153716

llvm-svn: 153715

property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration.

Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart.

Fixes rdar://11026482

llvm-svn: 153714

Fixed an issue that could cause circular type parsing that will assert and kill LLDB.

Prior to this fix the DWARF parser would always create class types and not start their definitions (for both C++ and ObjC classes) until we were asked to complete the class later. When we had cases like:

class A
{
    class B
    {
    };
};

We would alway try to complete A before specifying "A" as the decl context for B. Turns out we can just start the definition and still not complete the class since we can check the TagDecl::isCompleteDefinition() function. This only works for C++ types. This means we will not be pulling in the full definition of parent classes all the time and should help with our memory consumption and also reduce the amount of debug info we have to parse.

I also reduced redundant code that was checking in a lldb::clang_type_t was a possible C++ dynamic type since it was still completing the type, just to see if it was dynamic. This was fixed in another function that was checking for a type being dynamic as an ObjC or a C++ type, but there was dedicated fucntion for C++ that we missed.

llvm-svn: 153713

Fixing a whole class of crashers and potential crashers related to data formatters eating up all the stack when an unknown class has to be summarized ; this should make the whole Objective-C summaries more stable

llvm-svn: 153712

llvm-svn: 153711

section. A 'normal' string will go into the __TEXT,__const section, but this
isn't good for UTF16 strings. The __ustring section allows for coalescing, among
other niceties (such as allowing the linker to easily split up strings).

Instead of outputting the UTF16 string as a series of bytes, output it as a
series of shorts. The back-end will then nicely place the UTF16 string into the
correct section, because it's a mensch.
<rdar://problem/10655949>

llvm-svn: 153710

reference is going to message the setter, the getter, or both.

Having this info on the ObjCPropertyRefExpr node makes it easier for AST
clients (like libclang) to reason about the meaning of the property reference.

[AST/Sema]
-Use 2 bits (with a PointerIntPair) in ObjCPropertyRefExpr to record the above info
-Have ObjCPropertyOpBuilder set the info appropriately.

[libclang]
-When there is an implicit property reference (property syntax using methods)
have clang_getCursorReferenced return a cursor for the method. If the property
reference is going to result in messaging both the getter and the setter choose
to return a cursor for the setter because it is less obvious from source inspection
that the setter is getting called.

The general idea has the seal of approval by John.

rdar://11151621

llvm-svn: 153709

its location the location of the property.

Part of rdar://11113120

llvm-svn: 153708

-the location of the cursor
-its extent
-its spelling

Part of radar://11113120

llvm-svn: 153707

llvm-svn: 153706

here but it has no other uses, then we have a problem. E.g.,

  int foo (const int *x) {
    char a[*x];
    return 0;
  }

If we assign 'a' a vreg and fast isel later on has to use the selection
DAG isel, it will want to copy the value to the vreg. However, there are
no uses, which goes counter to what selection DAG isel expects.
<rdar://problem/11134152>

llvm-svn: 153705

load.

llvm-svn: 153704

Extend -Wc++11-narrowing to cover converted constant expressions as well as braced-initializers.  <rdar://problem/11121178>.

llvm-svn: 153703

Includes a test from a reported false positive fixed in some earlier
commit.

llvm-svn: 153702

llvm-svn: 153701

This pass splits basic blocks to insert constant islands, and it
doesn't recompute the live-in lists. No later passes depend on accurate
liveness information.

This fixes PR12410 where the machine code verifier was complaining.

llvm-svn: 153700

We are sometimes allocatinog from the DPair register class which
contains odd-even pairs in addition to the Q registers.

Place the Q registers first in the DPair allocation order as they can be
copied with a single instruction. The odd-even pairs should only be
allocated as a last resort.

llvm-svn: 153699

llvm-svn: 153698

llvm-svn: 153697

vmov.f32.

llvm-svn: 153696

llvm-svn: 153695

Added ExecutionEngine/MCJIT tests.

llvm-svn: 153694

Symbol files (dSYM files on darwin) can now be specified during program execution:

(lldb) target symbols add /path/to/symfile/a.out.dSYM/Contents/Resources/DWARF/a.out

This command can be used when you have a debug session in progress and want to add symbols to get better debug info fidelity.

llvm-svn: 153693

llvm-svn: 153691

The CMP->CMN alias was matching for an immediate of zero when it
should only match for negative values.

rdar://11129224

llvm-svn: 153689

testcase require asserts.

llvm-svn: 153687

ARM recently gained DPair, DTriple, and DQuad register classes.
Update copyPhysReg() to handle copies in these register classes.

No test case, it is difficult to make the register allocator emit the
odd copies reliably. The missing DPair copy caused a failure on
partialsums in the nightly test suite.

<rdar://problem/11147997>

llvm-svn: 153686

Line tables when using DWARF in .o files can be wrong when two entries get moved around by the compiler. This was due to incorrect logic in the line entry comparison operator.

llvm-svn: 153685

llvm-svn: 153684

llvm-svn: 153683

llvm-svn: 153680

llvm-svn: 153678

llvm-svn: 153677

Part 1 of a series of fixes meant to improve reliability and increase ease of bug fixing for data formatter issues.
We are introducing a new Logger class on the Python side. This has the same purpose, but is unrelated, to the C++ logging facility
The Pythonic logging can be enabled by using the following scripting commands:
(lldb) script Logger._lldb_formatters_debug_level = {0,1,2,...}
0 = no logging
1 = do log
2 = flush after logging each line - slower but safer
3 or more = each time a Logger is constructed, log the function that has created it
more log levels may be added, each one being more log-active than the previous
by default, the log output will come out on your screen, to direct it to a file:
(lldb) script Logger._lldb_formatters_debug_filename = 'filename'
that will make the output go to the file - set to None to disable the file output and get screen logging back
Logging has been enabled for the C++ STL formatters and for Cocoa class NSData - more logging will follow


synthetic children providers for classes list and map (both libstdcpp and libcxx) now have internal capping for safety reasons
this will fix crashers where a malformed list or map would not ever meet our termination conditions

to set the cap to a different value:

(lldb) script {gnu_libstdcpp|libcxx}.{map|list}_capping_size = new_cap (by default, it is 255)

you can optionally disable the loop detection algorithm for lists

(lldb) script {gnu_libstdcpp|libcxx}.list_uses_loop_detector = False

llvm-svn: 153676

for unbacked properties.  We support two variants:
one in which the getter/setter are provided by
selector ("mySetter:") and one in which the
getter/setter are provided by signature 
("-[MyClass mySetter:]").

llvm-svn: 153675