- s/skipOnLinux/skipIfLinux/ to match style of every other decorator
- linkify bugizilla/PR numbers in comments

No intended change in functionality.

llvm-svn: 181913

llvm-svn: 181845

Fixed the test case to pass on Darwin. This might pass on linux as well. The test case now properly validates g_points as a global for the class A version, and the static variable for the file static.

llvm-svn: 181840

llvm-svn: 181741

llvm-svn: 181613

Skipping a test that asserts with gcc and icc to allow the test suite to run to completion on the gcc buildbot.

llvm-svn: 181512

llvm-svn: 181486

value.  This fixes problems, for instance, with the StepRange plans, where they know that
they explained the stop because they were at their "run to here" breakpoint, then deleted
that breakpoint, so when they got asked again, doh!  I had done this for a couple of plans
in an ad hoc fashion, this just formalizes it.

Also add a "ResumeRequested" in Process so that the code in the completion handlers can
tell the ShouldStop logic they want to resume rather than just directly resuming.  That allows 
us to handle resuming in a more controlled fashion.

Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when
the target was immediately restarted.
--This line, and those below , will be ignored--

M    test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py
M    include/lldb/Target/ThreadList.h
M    include/lldb/Target/ThreadPlanStepOut.h
M    include/lldb/Target/Thread.h
M    include/lldb/Target/ThreadPlanBase.h
M    include/lldb/Target/ThreadPlanStepThrough.h
M    include/lldb/Target/ThreadPlanStepInstruction.h
M    include/lldb/Target/ThreadPlanStepInRange.h
M    include/lldb/Target/ThreadPlanStepOverBreakpoint.h
M    include/lldb/Target/ThreadPlanStepUntil.h
M    include/lldb/Target/StopInfo.h
M    include/lldb/Target/Process.h
M    include/lldb/Target/ThreadPlanRunToAddress.h
M    include/lldb/Target/ThreadPlan.h
M    include/lldb/Target/ThreadPlanCallFunction.h
M    include/lldb/Target/ThreadPlanStepOverRange.h
M    source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
M    source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
M    source/Target/StopInfo.cpp
M    source/Target/Process.cpp
M    source/Target/ThreadPlanRunToAddress.cpp
M    source/Target/ThreadPlan.cpp
M    source/Target/ThreadPlanCallFunction.cpp
M    source/Target/ThreadPlanStepOverRange.cpp
M    source/Target/ThreadList.cpp
M    source/Target/ThreadPlanStepOut.cpp
M    source/Target/Thread.cpp
M    source/Target/ThreadPlanBase.cpp
M    source/Target/ThreadPlanStepThrough.cpp
M    source/Target/ThreadPlanStepInstruction.cpp
M    source/Target/ThreadPlanStepInRange.cpp
M    source/Target/ThreadPlanStepOverBreakpoint.cpp
M    source/Target/ThreadPlanStepUntil.cpp
M    lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme

llvm-svn: 181381

Mark TestConstVariables as expected to fail due to radar 13314878 on darwin. The tests are already skipped on linux.

llvm-svn: 180965

Linux; marking as such.

llvm-svn: 180832

functions can be called by basename.

<rdar://problem/13709855>

llvm-svn: 180814

access to 'z' where 'z' was not in scope.

llvm-svn: 180662

Mark tests as expected fail for Linux due to not being able to call/print c++ demangled functions in the global namespace (bugzilla 15854).

llvm-svn: 180623

sent to "super".

<rdar://problem/13042260>

llvm-svn: 180217

<rdar://problem/12977827>

llvm-svn: 180215

out of the runtime.  This allows calling static methods
on classes whose symbols have been stripped out of the
binary.

<rdar://problem/12042992>

llvm-svn: 180210

not find multiple functions with the same name but
different types.  Now we keep track of what types
we've already reported for a function and only elide
functions if we've already reported a conflicting
one.

Also added a test case.

<rdar://problem/11367837>

llvm-svn: 180167

- New tests can fail on OS/X and Linux, and illustrate that the compiler
used to generate the DWARF can result in lldb providing clang with an
external AST source that doesn't describe all required struct fields.

- Also includes test coverage for expressions with structs that do work on Linux- Also includes a test for dereferencing a null pointer to a struct, which works on OS/X rather than complaining, and complains on Linux with an upstream error that is really a side issue.

Thanks to Samuel, Andy and Daniel for their input.

llvm-svn: 179884

This prevents unbounded reads (i.e. reads of GetMaximumSizeOfStringSummary() bytes)
from causing test failures (i.e. due to ptrace EIO or EFAULT on Linux).

Note that ReadCStringFromMemory is marked as deprecated because the loop that calls
ReadMemory does not continue until the string has been completely read.
The expected behavior is to read until until max_bytes or a null terminator.

Note: As discussed on lldb-dev, further testing will be performed with ReadStringFromMemory
before further changes are made for users of ReadCStringFromMemory.

Thanks to Enrico, Matt and Andy for their review feedback.

llvm-svn: 179857

This makes the dynamic values test case work for both libc++ and libstdcpp

llvm-svn: 179333

llvm-svn: 178295

Fixed incorrect python that was trying to validate that we got a valid lldb.SBThread object by checking to see if it is equal to "None". 

This test is incorrect as functions that return lldb.SBThread objects never return None, they just return lldb.SBThread objects that contain invalid opaque classes. 

llvm-svn: 177416

-adds icc to the lit of compilers to run the tests
-adds icc test decorators
-skip TestAnonymous.py for icc

Patch by Ashok Thirumurthi.

llvm-svn: 177174

- fix TestCPPBool (was failing with some versions of GCC due to num_breakpoint_locations)
- speed up tests by skipping git/svn revision parsing by the test harness when running in lit-compatible (parsable) mode

This should resolve the failures reported by http://lab.llvm.org:8011/builders/lldb-x86_64-linux

llvm-svn: 176972

- Required flag "-std=c++11" needs to be set before including Makefile.rules

llvm-svn: 176644

The test was marked as expectedFailureLinux, but now it passes with gcc and some versions of clang.  Newer versions of clang introduce a failure due to bad DWARF information.

llvm-svn: 176581

Fixed enum printing for negative enums. There previously was no testing to validate that enum values were being displayed correctly.

Also added C++11 enum test cases to cover enums as int8_t, int16_t int32_t, int64_t, uint8_t, uint16_t, uint32_t, and uint64_t both for DWARF and dSYM cases. The DWARF being emitted by clang is missing the enum integer type, but the code is now ready to accept and deal with the integral type if it is supplied.

llvm-svn: 176548

llvm-svn: 176546

patch by Ashok Thirumurthi!

llvm-svn: 176462

- expected to fail across the board due to llvm.org/pr15401

Patch by Ashok Thirumurthi!

llvm-svn: 176362

llvm-svn: 176283

llvm-svn: 176281

llvm-svn: 176206

- pull up logic to get compiler version from TestUniqueTypes.py into lldbtest.py
- work around an GCC 4.6.3 issue

llvm-svn: 176190

llvm-svn: 176132

Remove the getCategory from TestDataFormatterObjC.py, since it was superceded by the .categories file, 
and didn't work anyway (getCategories currently has to be a method on the test class, not on the test.)
Add a "basic_process" category, and start to find some tests for simple process running sniff tests.

llvm-svn: 176061

Fixing issues in previous checkin - still figuring out how to make expectedFailureClang take the bugnumber

llvm-svn: 175945

The decorators @expectedFailure (plain and special-case like i386, clang, ...) are modified to optionally take a bugnumber argument
If such an argument is specified, the failure report (or unexpected success report) will include the information passed in as part of the message
This is mostly useful for associating failures to issue IDs in issue management systems (e.g. the LLVM bugzilla)

llvm-svn: 175942

llvm-svn: 175917

Turns out unnamed bit fields should not be accessed ever in C (C99 section 4.7.8) or C++
(C++11 section 9.6). 

Unrelated to the above, this commit marks TestBitfields as expected-to-fail with GCC as 4.7
has problems with padding... the size of the struct with a uint32_t member is reported as 12
when GCC is used. Clang emits correct code.

Parts of this patch prepared by Filipe Cabecinhas!

llvm-svn: 175666