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

1 files changed, 20 insertions, 25 deletions

diff --git a/lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp b/lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp
index 3896a0b2471..43b2d9f4c69 100644
--- a/lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp
+++ b/lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp
@@ -31,8 +31,8 @@ ThreadPlanStepOverBreakpoint::ThreadPlanStepOverBreakpoint(Thread &thread)
           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 @@ bool ThreadPlanStepOverBreakpoint::DoPlanExplainsStop(Event *event_ptr) {
   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 @@ bool ThreadPlanStepOverBreakpoint::DoPlanExplainsStop(Event *event_ptr) {
       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 @@ bool ThreadPlanStepOverBreakpoint::MischiefManaged() {
 
   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));