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, 15 insertions, 20 deletions

diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
index 62b88456b9d..4e20b56fb11 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.cpp
@@ -109,16 +109,14 @@ StateType GDBRemoteClientBase::SendContinuePacketAndWaitForResponse(
       const bool should_stop = ShouldStop(signals, response);
       response.SetFilePos(0);
 
-      // The packet we should resume with. In the future
-      // we should check our thread list and "do the right thing"
-      // for new threads that show up while we stop and run async
-      // packets. Setting the packet to 'c' to continue all threads
-      // is the right thing to do 99.99% of the time because if a
-      // thread was single stepping, and we sent an interrupt, we
-      // will notice above that we didn't stop due to an interrupt
-      // but stopped due to stepping and we would _not_ continue.
-      // This packet may get modified by the async actions (e.g. to send a
-      // signal).
+      // The packet we should resume with. In the future we should check our
+      // thread list and "do the right thing" for new threads that show up
+      // while we stop and run async packets. Setting the packet to 'c' to
+      // continue all threads is the right thing to do 99.99% of the time
+      // because if a thread was single stepping, and we sent an interrupt, we
+      // will notice above that we didn't stop due to an interrupt but stopped
+      // due to stepping and we would _not_ continue. This packet may get
+      // modified by the async actions (e.g. to send a signal).
       m_continue_packet = 'c';
       cont_lock.unlock();
 
@@ -263,19 +261,16 @@ bool GDBRemoteClientBase::ShouldStop(const UnixSignals &signals,
   if (m_async_count == 0)
     return true; // We were not interrupted. The process stopped on its own.
 
-  // Older debugserver stubs (before April 2016) can return two
-  // stop-reply packets in response to a ^C packet.
-  // Additionally, all debugservers still return two stop replies if
-  // the inferior stops due to some other reason before the remote
-  // stub manages to interrupt it. We need to wait for this
-  // additional packet to make sure the packet sequence does not get
-  // skewed.
+  // Older debugserver stubs (before April 2016) can return two stop-reply
+  // packets in response to a ^C packet. Additionally, all debugservers still
+  // return two stop replies if the inferior stops due to some other reason
+  // before the remote stub manages to interrupt it. We need to wait for this
+  // additional packet to make sure the packet sequence does not get skewed.
   StringExtractorGDBRemote extra_stop_reply_packet;
   ReadPacket(extra_stop_reply_packet, milliseconds(100), false);
 
-  // Interrupting is typically done using SIGSTOP or SIGINT, so if
-  // the process stops with some other signal, we definitely want to
-  // stop.
+  // Interrupting is typically done using SIGSTOP or SIGINT, so if the process
+  // stops with some other signal, we definitely want to stop.
   const uint8_t signo = response.GetHexU8(UINT8_MAX);
   if (signo != signals.GetSignalNumberFromName("SIGSTOP") &&
       signo != signals.GetSignalNumberFromName("SIGINT"))