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

llvm-svn: 181378

Constrain __invoke functions more accurately.  This fixes http://llvm.org/bugs/show_bug.cgi?id=15861 .

llvm-svn: 181377

C++1y constant expression evaluation: compound assignment support for floating-point and pointer types.

llvm-svn: 181376

a new section is added to the executable after the dSYM has been created, e.g.
the CTF segment added to mach_kernel after all other linking and processing has
been finished.
<rdar://problem/13258780> 

llvm-svn: 181375

llvm-svn: 181374

llvm-svn: 181373

llvm-svn: 181372

llvm-svn: 181371

return all the overloads instead of just picking the first possible declaration.
This removes an invalid note (and on occasion other invalid diagnostics) and
also makes clang's parsing recovery behave as if the text from its fixit were
applied.

llvm-svn: 181370

The two nested loops were confusing and also conservative in identifying
reduction variables. This patch replaces them by a worklist based approach.

llvm-svn: 181369

used as a branch condition.

llvm-svn: 181368

Adding some LLDB-specific logic to the tracer (in a separate tracer module) to improve the quality of the output when debugging data formatters
(more improvements are necessary before this is really legible)

llvm-svn: 181367

A = 9
B = 3 * A - 2 * A + 1 as  B = 3 * A - (2 * A + 1)

rdar://13816516

llvm-svn: 181366

This is a fix for PR15895, where Clang will crash when trying to print a
template diff and the template uses an address of operator.  This resulted
from expecting a DeclRefExpr when the Expr could have also been
UnaryOperator->DeclRefExpr.

llvm-svn: 181365

DIBuilder::createImportedDeclaration isn't fully plumbed through (note,
lacking in AsmPrinter/DwarfDebug support) but this seemed like a
sufficiently useful division of code to make the subsequent patch(es)
easier to follow.

llvm-svn: 181364

Patch by Kai Nacke!

llvm-svn: 181363

[analyzer;alternate arrows] Fix inconsistencies in recorded location context when handling interprocedural paths.

llvm-svn: 181362

llvm-svn: 181361

llvm-svn: 181360

llvm-svn: 181359

llvm-svn: 181358

llvm-svn: 181357

llvm-svn: 181356

No functional change.

llvm-svn: 181355

llvm-svn: 181354

llvm-svn: 181353

rdar://13680583

llvm-svn: 181352

llvm-svn: 181351

llvm-svn: 181350

The idea is that docs/ReleaseNotes.rst is 3.3 and will be copied to the
branch by the release manager just before creating the release
candidates.

This ReleaseNotes_34.rst will then be moved over ReleaseNotes.rst after
the 3.3 release.

llvm-svn: 181349

llvm-svn: 181348

Introduce _LIBCPP_STD_VER.  This can be set by the client (or the clang driver).  Or it will be defaulted.  The default is 11 if -std= c++11 or eariler, else it will default to the current year modulo the century.  We anticipate it defaulting to 14 for C++14 when the time comes.  For now, post-C++11 libcxx implementations should protect themselves with #if _LIBCPP_STD_VER > 11.

llvm-svn: 181347

llvm-svn: 181346

rdar://13829073

llvm-svn: 181345

llvm-svn: 181344

This module uses Python's sys.settrace() mechanism so setup a hook that can log every significant operation
This is a first step in providing a good debugging experience of Python embedded in LLDB
This module comprises an OO infrastructure that wraps Python's tracing and inspecting mechanisms, plus a very simple logging tracer
Output from this tracer looks like:

call print_keyword_args from <module> @ 243 args are kwargs are {'first_name': 'John', 'last_name': 'Doe'}
running print_keyword_args @ 228 locals are {'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
running print_keyword_args @ 229 locals are {'key': 'first_name', 'value': 'John', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
first_name = John
running print_keyword_args @ 228 locals are {'key': 'first_name', 'value': 'John', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
running print_keyword_args @ 229 locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
last_name = Doe
running print_keyword_args @ 228 locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
return from print_keyword_args value is None locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}

llvm-svn: 181343

C++1y: Update __cplusplus to temporary value 201305L to allow detection of provisional C++1y support.
Add __has_feature and __has_extension checks for C++1y features (based on the provisional names from
the C++ features study group), and update documentation to match.

llvm-svn: 181342

llvm-svn: 181341

llvm-svn: 181340