[binutils-gdb] Change type of struct complaints::series

[Simon Marchi <simark at sourceware dot org>]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=05d999b0896ab6ccd4ce23a715765484c60a967d

commit 05d999b0896ab6ccd4ce23a715765484c60a967d
Author: Simon Marchi <simon.marchi@ericsson.com>
Date:   Thu Aug 6 12:01:05 2015 -0400

    Change type of struct complaints::series
    
    Found while processing the C++ enum changes.  It seems like series
    should be of type enum complaint_series, instead of adding a cast.
    
    Redundant and out of date comments are also removed.
    
    gdb/ChangeLog:
    
    	* complaints.c (enum complaint_series): Add newlines and remove
    	out of date comment.
    	(struct complaints) <series>: Change type to enum
    	complaint_series and remove out of date comment.
    	(symfile_complaint_hook): Use equivalent enum value
    	ISOLATED_MESSAGE instead of 0.

Diff:
---
 gdb/ChangeLog    |  9 +++++++++
 gdb/complaints.c | 17 +++++------------
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 193581f..6c854ac 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,12 @@
+2015-08-06  Simon Marchi  <simon.marchi@ericsson.com>
+
+	* complaints.c (enum complaint_series): Add newlines and remove
+	out of date comment.
+	(struct complaints) <series>: Change type to enum
+	complaint_series and remove out of date comment.
+	(symfile_complaint_hook): Use equivalent enum value
+	ISOLATED_MESSAGE instead of 0.
+
 2015-08-06  Pedro Alves  <palves@redhat.com>
 
 	* nat/linux-waitpid.c (my_waitpid): Only print *status if waitpid
diff --git a/gdb/complaints.c b/gdb/complaints.c
index dbacb2a..b696181 100644
--- a/gdb/complaints.c
+++ b/gdb/complaints.c
@@ -27,18 +27,17 @@ extern void _initialize_complaints (void);
 /* Should each complaint message be self explanatory, or should we
    assume that a series of complaints is being produced?  */
 
-/* case 1: First message of a series that must
-   start off with explanation.  case 2: Subsequent message of a series
-   that needs no explanation (the user already knows we have a problem
-   so we can just state our piece).  */
 enum complaint_series {
   /* Isolated self explanatory message.  */
   ISOLATED_MESSAGE,
+
   /* First message of a series, includes an explanation.  */
   FIRST_MESSAGE,
+
   /* First message of a series, but does not need to include any sort
      of explanation.  */
   SHORT_FIRST_MESSAGE,
+
   /* Subsequent message of a series that needs no explanation (the
      user already knows we have a problem so we can just state our
      piece).  */
@@ -69,13 +68,7 @@ struct complaints
 {
   struct complain *root;
 
-  /* Should each complaint be self explanatory, or should we assume
-     that a series of complaints is being produced?  case 0: Isolated
-     self explanatory message.  case 1: First message of a series that
-     must start off with explanation.  case 2: Subsequent message of a
-     series that needs no explanation (the user already knows we have
-     a problem so we can just state our piece).  */
-  int series;
+  enum complaint_series series;
 
   /* The explanatory messages that should accompany the complaint.
      NOTE: cagney/2002-08-14: In a desperate attempt at being vaguely
@@ -99,7 +92,7 @@ static struct explanation symfile_explanations[] = {
 
 static struct complaints symfile_complaint_book = {
   &complaint_sentinel,
-  0,
+  ISOLATED_MESSAGE,
   symfile_explanations
 };
 struct complaints *symfile_complaints = &symfile_complaint_book;