during the finalization for CGDebugInfo in clang we would RAUW
a type and it would result in a corrupted MDNode for an
imported declaration.

Testcase pending as reducing has been difficult.

llvm-svn: 202540

Was r202442

There were two issues with the original patch that have now been fixed.
1. We were memset'ing over a FileEntry in a test case. After adding a
   std::string to FileEntry, this still happened to not break for me.
2. I didn't pass the FileManager into the new compiler instance in
   compileModule. This was hidden in some cases by the fact I didn't
   clear the module cache in the test.

Also, I changed the copy constructor for FileEntry, which was memcpy'ing
in a (now) unsafe way.

llvm-svn: 202539

llvm-svn: 202538

llvm-svn: 202537

Be sure to propagate the error back out SBTarget::Attach() when we fail to launch debugserver as root.

<rdar://problem/15669788>

llvm-svn: 202536

llvm-svn: 202535

llvm-svn: 202534

Fix a minor bug in lexing pp-numbers with digit separators: if a pp-number contains "'e+", the pp-number ends between the 'e' and the '+'.

llvm-svn: 202533

llvm-svn: 202532

llvm-svn: 202531

Tools that use the CommandLine library currently exit with an error
when invoked with -version or -help. This is unusual and non-standard,
so we'll fix them to exit successfully instead.

I don't expect that anyone relies on the current behaviour, so this
should be a fairly safe change.

llvm-svn: 202530

When completing Objective-C instance method invocations, perform a contextual conversion to an Objective-C pointer type of the target expression if needed. This fixes code completion of method invocations where the target is a smart pointer that has an explicit conversion operator to an Objective-C type.

llvm-svn: 202529

llvm-svn: 202528

llvm-svn: 202527

llvm-svn: 202526

I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion.

<rdar://problem/16111293>

llvm-svn: 202525

We were only using it so find the shared library extension and nm. There are
simpler ways to do those things :-)

llvm-svn: 202524

llvm-svn: 202523

llvm-svn: 202522

llvm-svn: 202521

won't work (i.e. when not doing a member lookup and not in a method from
the same class or a descendant class).

llvm-svn: 202520

llvm-svn: 202519

llvm-svn: 202518

I suspect I may have misrun the test previously for check-in
r202456 re: pr15258.  This test fails consistently on my end.
I changed the test to expected failure on Linux.

llvm-svn: 202517

This worked 25 out of 25 times for me on Ubuntu 12.04 LTS x86_64 built
with gcc 4.8.2 and the July 2013 libedit.

llvm-svn: 202516

TestRegisterVariables.test_with_dwarf_and_run_command was being
skipped on Linux due to issues with clang. I converted it to a
@expectedFailureClang and no longer skip on Linux.

llvm-svn: 202515

TestConstVariables.py was disabled on Linux and marked as
unconditional expected failure. This change removes the Linux disable
and makes the expected failure conditional on using clang. The test
runs fine on gcc-built lldb.

llvm-svn: 202514

This was broken in the threaded inferior implementation for FreeBSD
(r196787) and caused FreeBSD to resume always with no signal.

llvm-svn: 202513

This test passed 50 out of 50 times for me on Unbuntu 12.04 LTS x86_64
with lldb built using gcc 4.8.2 and July 2013 libedit.

This is related to:
http://llvm.org/bugs/show_bug.cgi?id=16170

llvm-svn: 202512

Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=16714

On TOT lldb svn r202507, I found several of the tests disabled within
TestConcurrentEvents.py to run fine, and several of them to fail 100%
of the time on my system (25 out of 25 times).

This changes the following tests for Linux:

Enables (these all work consistently):
* test_many_watchpoints_dwarf
* test_signal_watch_break_dwarf (line 250)
* test_signal_watch_break_dwarf (line 260 - same named test?)
* test_crash_with_watchpoint_dwarf
* test_crash_with_watchpoint_breakpoint_signal_dwarf
* test_delayed_crash_with_breakpoint_watchpoint_dwarf

Marks as expected failure (these all fail consistently):
* test_many_watchpoints_dwarf
* test_watch_break_dwarf
* test_delay_watch_break_dwarf
* test_watch_break_dwarf_delay
* test_signal_watch_dwarf
* test_delay_signal_watch_dwarf
* test_signal_delay_watch_dwarf
* test_two_breakpoints_one_watchpoint_dwarf
* test_breakpoints_delayed_breakpoint_one_watchpoint_dwarf
* test_two_watchpoint_threads_dwarf
* test_watchpoint_with_delay_watchpoint_threads_dwarf
* test_two_watchpoints_one_breakpoint_dwarf
* test_two_watchpoints_one_delay_breakpoint_dwarf
* test_watchpoint_delay_watchpoint_one_breakpoint_dwarf
* test_two_watchpoints_one_signal_dwarf
* test_signal_watch_break_dwarf

llvm-svn: 202511

llvm-svn: 202510

This lets us run the unittest from the command line without setting
LD_LIBRARY_PATH.

llvm-svn: 202509

This is related to:
http://llvm.org/bugs/show_bug.cgi?id=16170

This test ran successfully 40 out of 40 times on Ubuntu 12.04 LTS
x86_64.

llvm-svn: 202508

Similar to my previous check-in related to:
http://llvm.org/bugs/show_bug.cgi?id=15037

10 out of 10 runs of this failed.  Mark it XFAIL.

llvm-svn: 202507

Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=15037

Previously this was marked as skipped. I tried running it 10 times in
a row and it failed every time. Switched it to XFAIL.

llvm-svn: 202506

llvm-svn: 202505

llvm-svn: 202504

llvm-svn: 202503

llvm-svn: 202502

Adding a test case to ensure that type attributes applied to the decl-specifier are applied across all declarations in a group.

llvm-svn: 202501