| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This patch adds the SBReproducer macros needed to capture and reply the
corresponding calls. This patch was generated by running the lldb-instr
tool on the API source files.
Differential revision: https://reviews.llvm.org/D57475
llvm-svn: 355459
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
|
|
| |
recognized arguments by default
Differential Revision: https://reviews.llvm.org/D55954
llvm-svn: 349856
|
|
|
|
|
|
|
| |
Removes redundant calls to ::get() from smart pointers in the source/API
directory..
llvm-svn: 349821
|
|
|
|
|
|
|
|
| |
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345693
|
|
|
|
| |
llvm-svn: 345688
|
|
|
|
|
|
|
|
| |
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345686
|
|
|
|
| |
llvm-svn: 345680
|
|
|
|
|
|
|
|
| |
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345678
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
|
|
|
|
|
|
|
|
|
| |
with yet another bool argument""
Reverting this commit led to other failures which I did not see at
first. This turned out to be an easy problem to fix, so I added
SBVariablesOptions.cpp to the CMakeLists.txt. In the future please
try to make sure new files are added to CMake.
llvm-svn: 229516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
another bool argument"
This reverts commit r228975. It was causing link errors
on the Windows bots, since last Thursday.
http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/725
Conflicts:
lldb.xcodeproj/project.pbxproj
llvm-svn: 229514
|
|
bool argument
We talked about it internally - and came to the conclusion that it's time to have an options class
This commit adds an SBVariablesOptions class and goes through all the required dance
llvm-svn: 228975
|