summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/expression_command/radar_9531204
diff options
context:
space:
mode:
authorKate Stone <katherine.stone@apple.com>2016-09-06 20:57:50 +0000
committerKate Stone <katherine.stone@apple.com>2016-09-06 20:57:50 +0000
commitb9c1b51e45b845debb76d8658edabca70ca56079 (patch)
treedfcb5a13ef2b014202340f47036da383eaee74aa /lldb/packages/Python/lldbsuite/test/expression_command/radar_9531204
parentd5aa73376966339caad04013510626ec2e42c760 (diff)
downloadbcm5719-llvm-b9c1b51e45b845debb76d8658edabca70ca56079.tar.gz
bcm5719-llvm-b9c1b51e45b845debb76d8658edabca70ca56079.zip
*** 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
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/radar_9531204')
-rw-r--r--lldb/packages/Python/lldbsuite/test/expression_command/radar_9531204/TestPrintfAfterUp.py10
1 files changed, 6 insertions, 4 deletions
diff --git a/lldb/packages/Python/lldbsuite/test/expression_command/radar_9531204/TestPrintfAfterUp.py b/lldb/packages/Python/lldbsuite/test/expression_command/radar_9531204/TestPrintfAfterUp.py
index e0b219dbe2b..c4d899cfc1e 100644
--- a/lldb/packages/Python/lldbsuite/test/expression_command/radar_9531204/TestPrintfAfterUp.py
+++ b/lldb/packages/Python/lldbsuite/test/expression_command/radar_9531204/TestPrintfAfterUp.py
@@ -5,13 +5,14 @@ The evaluating printf(...) after break stop and then up a stack frame.
from __future__ import print_function
-
-import os, time
+import os
+import time
import lldb
from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
from lldbsuite.test import lldbutil
+
class Radar9531204TestCase(TestBase):
mydir = TestBase.compute_mydir(__file__)
@@ -24,7 +25,8 @@ class Radar9531204TestCase(TestBase):
self.runCmd("file a.out", CURRENT_EXECUTABLE_SET)
- lldbutil.run_break_set_by_symbol (self, 'foo', sym_exact=True, num_expected_locations=1)
+ lldbutil.run_break_set_by_symbol(
+ self, 'foo', sym_exact=True, num_expected_locations=1)
self.runCmd("run", RUN_SUCCEEDED)
@@ -35,7 +37,7 @@ class Radar9531204TestCase(TestBase):
# rdar://problem/9531204
# "Error dematerializing struct" error when evaluating expressions "up" on the stack
- self.runCmd('up') # frame select -r 1
+ self.runCmd('up') # frame select -r 1
self.runCmd("frame variable")
OpenPOWER on IntegriCloud