| 102b2c2681c9a830afe25bfea35557421905e42c |
|
19-Apr-2013 |
Greg Clayton <gclayton@apple.com> |
After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Utility/PriorityPointerPair.h
|
| 598df88bd6fc33c6fb330bc859bdc277795501f3 |
|
14-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10434005>
Prepare LLDB to be built with C++11 by hiding all accesses to std::tr1 behind
macros that allows us to easily compile for either C++.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152698 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Utility/PriorityPointerPair.h
|
| 13d24fb1817faa7ccc4cfd799113ba1a2b8968eb |
|
29-Jan-2012 |
Greg Clayton <gclayton@apple.com> |
Switching back to using std::tr1::shared_ptr. We originally switched away
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.
The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.
So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive
pointers).
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149207 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Utility/PriorityPointerPair.h
|
| f7a9b14c2c02d2fa9fad586c19f29d77533fcc09 |
|
15-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Python summary strings:
- you can use a Python script to write a summary string for data-types, in one of
three ways:
-P option and typing the script a line at a time
-s option and passing a one-line Python script
-F option and passing the name of a Python function
these options all work for the "type summary add" command
your Python code (if provided through -P or -s) is wrapped in a function
that accepts two parameters: valobj (a ValueObject) and dict (an LLDB
internal dictionary object). if you use -F and give a function name,
you're expected to define the function on your own and with the right
prototype. your function, however defined, must return a Python string
- test case for the Python summary feature
- a few quirks:
Python summaries cannot have names, and cannot use regex as type names
both issues will be fixed ASAP
major redesign of type summary code:
- type summary working with strings and type summary working with Python code
are two classes, with a common base class SummaryFormat
- SummaryFormat classes now are able to actively format objects rather than
just aggregating data
- cleaner code to print descriptions for summaries
the public API now exports a method to easily navigate a ValueObject hierarchy
New InputReaderEZ and PriorityPointerPair classes
Several minor fixes and improvements
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135238 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Utility/PriorityPointerPair.h
|