Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3 |
|
#
d35b42f2 |
| 21-Aug-2019 |
Jonas Devlieghere <jonas@devlieghere.com> |
[NFC] Return llvm::StringRef from StringExtractor::GetStringRef.
This patch removes the two variant of StringExtractor::GetStringRef that return (non-)const references to std::string. The non-const
[NFC] Return llvm::StringRef from StringExtractor::GetStringRef.
This patch removes the two variant of StringExtractor::GetStringRef that return (non-)const references to std::string. The non-const one was being abused to reinitialize the StringExtractor and its uses are replaced by calls to the copy asignment operator. The const variant was refactored to return an actual llvm::StringRef.
llvm-svn: 369493
show more ...
|
Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2 |
|
#
248a1305 |
| 23-May-2019 |
Konrad Kleine <kkleine@redhat.com> |
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codeba
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information.
This is the command I ran and I to fix and format the code base:
``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ```
NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
show more ...
|
Revision tags: llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1, llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
#
b69c3169 |
| 17-Oct-2016 |
Justin Bogner <mail@justinbogner.com> |
unittests: Specify types in a bunch of unittest EXPECT's
The EXPECT and ASSERT macros in gtest don't do the usual arithmetic conversions. Specify types in several of them to fix -Werror.
llvm-svn:
unittests: Specify types in a bunch of unittest EXPECT's
The EXPECT and ASSERT macros in gtest don't do the usual arithmetic conversions. Specify types in several of them to fix -Werror.
llvm-svn: 284405
show more ...
|
#
b9c1b51e |
| 06-Sep-2016 |
Kate Stone <katherine.stone@apple.com> |
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications:
Firstly, merging t
*** This commit represents a complete reformatting of the LLDB source code *** 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
show more ...
|
#
90999010 |
| 31-Aug-2016 |
Zachary Turner <zturner@google.com> |
Add more unit tests for StringExtractor hex/endian functions.
There were a few corner cases that weren't tested for dealing with extraction of an odd number of nibbles. Add tests for those here.
l
Add more unit tests for StringExtractor hex/endian functions.
There were a few corner cases that weren't tested for dealing with extraction of an odd number of nibbles. Add tests for those here.
llvm-svn: 280253
show more ...
|
#
b9739d40 |
| 31-Aug-2016 |
Pavel Labath <labath@google.com> |
Revert r280137 and 280139 and subsequent build fixes
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes lldb-server crash. The crash (assert) happens when parsin
Revert r280137 and 280139 and subsequent build fixes
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes lldb-server crash. The crash (assert) happens when parsing the "qRegisterInfo0" packet, because the function tries to drop_front more bytes than the packet contains. It's not clear to me whether we should consider this a bug in the caller or the callee, but it any case, it worked before, so I am reverting this until we can figure out what the proper interface should be.
llvm-svn: 280207
show more ...
|
#
2d240d00 |
| 30-Aug-2016 |
Zachary Turner <zturner@google.com> |
A few minor stylistic cleanups in StringExtractor.
Makes Peek() return a StringRef instead of a const char*.
This leads to a few callers of Peek() being able to be made a little nicer (for example
A few minor stylistic cleanups in StringExtractor.
Makes Peek() return a StringRef instead of a const char*.
This leads to a few callers of Peek() being able to be made a little nicer (for example using StringRef member functions instead of c-style strncmp and related functions) and generally safer usage.
llvm-svn: 280139
show more ...
|
#
eb666b7a |
| 30-Aug-2016 |
Zachary Turner <zturner@google.com> |
Add a few more unit tests for StringExtractor.
This is a NFC that adds more unit test coverage of the GetHex*** functions as well as the functions to extract numbers with a specific endianness.
llv
Add a few more unit tests for StringExtractor.
This is a NFC that adds more unit test coverage of the GetHex*** functions as well as the functions to extract numbers with a specific endianness.
llvm-svn: 280124
show more ...
|
#
d08f09c1 |
| 30-Aug-2016 |
Zachary Turner <zturner@google.com> |
Convert some StringExtractor functions to accept MutableArrayRefs.
MutableArrayRef<T> is essentially a safer version of passing around (T*, length) pairs and provides some convenient functions for w
Convert some StringExtractor functions to accept MutableArrayRefs.
MutableArrayRef<T> is essentially a safer version of passing around (T*, length) pairs and provides some convenient functions for working with the data without having to manually manipulate indices.
This is a minor NFC.
llvm-svn: 280123
show more ...
|
#
54695a33 |
| 29-Aug-2016 |
Zachary Turner <zturner@google.com> |
Convert GetNameColonValue to return StringRefs.
StringExtractor::GetNameColonValue() looks for a substring of the form "<name>:<value>" and returns <name> and <value> to the caller. This results in
Convert GetNameColonValue to return StringRefs.
StringExtractor::GetNameColonValue() looks for a substring of the form "<name>:<value>" and returns <name> and <value> to the caller. This results in two unnecessary string copies, since the name and value are not translated in any way and simply returned as-is.
By converting this to return StringRefs we can get rid of hundreds of string copies.
llvm-svn: 280000
show more ...
|
#
05c4ceba |
| 27-Aug-2016 |
Zachary Turner <zturner@google.com> |
Add some unit tests for StringExtractor::GetNameColonValue.
These are helpful on their own, but will be even more useful once the GetNameColonValue is updated to return StringRefs instead of std::st
Add some unit tests for StringExtractor::GetNameColonValue.
These are helpful on their own, but will be even more useful once the GetNameColonValue is updated to return StringRefs instead of std::strings.
llvm-svn: 279919
show more ...
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1 |
|
#
28529f60 |
| 07-Jul-2015 |
Bruce Mitchener <bruce.mitchener@gmail.com> |
Fix StringExtractor.h issues.
Summary: Fix StringExtractor.h issues.
* source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp (#include "Utility/StringExtractor.h): Not needed, this is already i
Fix StringExtractor.h issues.
Summary: Fix StringExtractor.h issues.
* source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp (#include "Utility/StringExtractor.h): Not needed, this is already included by ProcessKDP.h
* unittests/Utility/StringExtractorTest.cpp (#include "Utility/StringExtractor.h): Update include path to the new location.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10995
llvm-svn: 241596
show more ...
|
Revision tags: llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1 |
|
#
3dfb86b6 |
| 17-Mar-2015 |
David Blaikie <dblaikie@gmail.com> |
Fix the clang -Werror build & make the unit tests link under Linux
The order of libraries passed to the linker didn't work under linux (you need the llvm libraries first, then the lldb libraries). I
Fix the clang -Werror build & make the unit tests link under Linux
The order of libraries passed to the linker didn't work under linux (you need the llvm libraries first, then the lldb libraries). I modelled this after clang's setup here. Seemed simple enough to just be consistent.
llvm-svn: 232461
show more ...
|
#
719ec93a |
| 13-Mar-2015 |
Zachary Turner <zturner@google.com> |
Rework the gtest directory structure.
This makes the directory structure mirror the canonical LLVM directory structure for a gtest suite.
Additionally, this patch deletes the xcode project. Nobody
Rework the gtest directory structure.
This makes the directory structure mirror the canonical LLVM directory structure for a gtest suite.
Additionally, this patch deletes the xcode project. Nobody is currently depending on this, and it would be better to have gtest unit tests be hand-maintained in the Xcode workspace rather than using this python test runner. Patches to that effect will be submitted as followups.
llvm-svn: 232211
show more ...
|