bcm5719-llvm/lldb/packages/Python/lldbsuite/test/functionalities/multidebugger_commands, branch meklort-10.0.1Project Ortega BCM5719 LLVMhttps://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.12019-08-02T08:06:22+00:00[lldb][NFC] Remove unused imports in python tests2019-08-02T08:06:22+00:00Raphael Isemannteemperor@gmail.com2019-08-02T08:06:22+00:00urn:sha1:9eedbc4f266d1e49d335d48c4c0f717401d927d2
llvm-svn: 367663
*** This commit represents a complete reformatting of the LLDB source code2016-09-06T20:57:50+00:00Kate Stonekatherine.stone@apple.com2016-09-06T20:57:50+00:00urn:sha1:b9c1b51e45b845debb76d8658edabca70ca56079
*** 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
Change 'apropos' such that it doesn't look into the "long help/syntax" strings for commands2016-03-23T01:21:55+00:00Enrico Granataegranata@apple.com2016-03-23T01:21:55+00:00urn:sha1:d033e1cef5516d77f3712dd6d826153101c91507
This solves issues such as 'apropos foo' returning valid matches just because syntax examples happen to use 'foo' as a placeholder token
Fixes rdar://9043025
llvm-svn: 264123
Fix an issue where certain CommandObjects (or Options thereof) were being created once, bound to a specific CommandInterpreter (and hence a specific Debugger), and then cached for reuse across different Debugger instances2016-02-06T00:43:07+00:00Enrico Granataegranata@apple.com2016-02-06T00:43:07+00:00urn:sha1:0a66e2f13505f9cf9e8a37dc35cb68effedeb13d
Obviously, if the original Debugger goes away, those commands are holding on to now stale memory, which has the potential to cause crashes
Fixes rdar://24460882
llvm-svn: 259964