Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
diff --git a/lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp b/lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp
index 3896a0b..43b2d9f 100644
--- a/lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp
+++ b/lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp
@@ -31,8 +31,8 @@
ThreadPlan::eKindStepOverBreakpoint, "Step over breakpoint trap",
thread, eVoteNo,
eVoteNoOpinion), // We need to report the run since this happens
- // first in the thread plan stack when stepping
- // over a breakpoint
+ // first in the thread plan stack when stepping over
+ // a breakpoint
m_breakpoint_addr(LLDB_INVALID_ADDRESS),
m_auto_continue(false), m_reenabled_breakpoint_site(false)
@@ -57,16 +57,15 @@
StopInfoSP stop_info_sp = GetPrivateStopInfo();
if (stop_info_sp) {
// It's a little surprising that we stop here for a breakpoint hit.
- // However, when you single step ONTO a breakpoint
- // we still want to call that a breakpoint hit, and trigger the actions,
- // etc. Otherwise you would see the
+ // However, when you single step ONTO a breakpoint we still want to call
+ // that a breakpoint hit, and trigger the actions, etc. Otherwise you
+ // would see the
// PC at the breakpoint without having triggered the actions, then you'd
// continue, the PC wouldn't change,
- // and you'd see the breakpoint hit, which would be odd.
- // So the lower levels fake "step onto breakpoint address" and return that
- // as a breakpoint. So our trace
- // step COULD appear as a breakpoint hit if the next instruction also
- // contained a breakpoint.
+ // and you'd see the breakpoint hit, which would be odd. So the lower
+ // levels fake "step onto breakpoint address" and return that as a
+ // breakpoint. So our trace step COULD appear as a breakpoint hit if the
+ // next instruction also contained a breakpoint.
StopReason reason = stop_info_sp->GetStopReason();
switch (reason) {
@@ -75,20 +74,17 @@
return true;
case eStopReasonBreakpoint:
// It's a little surprising that we stop here for a breakpoint hit.
- // However, when you single step ONTO a
- // breakpoint we still want to call that a breakpoint hit, and trigger the
- // actions, etc. Otherwise you
+ // However, when you single step ONTO a breakpoint we still want to call
+ // that a breakpoint hit, and trigger the actions, etc. Otherwise you
// would see the PC at the breakpoint without having triggered the
- // actions, then you'd continue, the PC
- // wouldn't change, and you'd see the breakpoint hit, which would be odd.
- // So the lower levels fake "step onto breakpoint address" and return that
- // as a breakpoint hit. So our trace
- // step COULD appear as a breakpoint hit if the next instruction also
- // contained a breakpoint. We don't want
- // to handle that, since we really don't know what to do with breakpoint
- // hits. But make sure we don't set
- // ourselves to auto-continue or we'll wrench control away from the plans
- // that can deal with this.
+ // actions, then you'd continue, the PC wouldn't change, and you'd see
+ // the breakpoint hit, which would be odd. So the lower levels fake "step
+ // onto breakpoint address" and return that as a breakpoint hit. So our
+ // trace step COULD appear as a breakpoint hit if the next instruction
+ // also contained a breakpoint. We don't want to handle that, since we
+ // really don't know what to do with breakpoint hits. But make sure we
+ // don't set ourselves to auto-continue or we'll wrench control away from
+ // the plans that can deal with this.
SetAutoContinue(false);
return false;
default:
@@ -130,8 +126,7 @@
if (pc_addr == m_breakpoint_addr) {
// If we are still at the PC of our breakpoint, then for some reason we
- // didn't
- // get a chance to run.
+ // didn't get a chance to run.
return false;
} else {
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_STEP));