public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [pushed] gdb: fix some clang-tidy readability-misleading-indentation warnings
@ 2022-01-31 17:23 Simon Marchi
  0 siblings, 0 replies; only message in thread
From: Simon Marchi @ 2022-01-31 17:23 UTC (permalink / raw)
  To: gdb-patches; +Cc: Simon Marchi

From: Simon Marchi <simon.marchi@efficios.com>

I have warnings like these showing in my editor all the time, so I
thought I'd run clang-tidy with this diagnostic on all the files (that I
can compile) and fix them.

There is still one warning, in utils.c, but that's because some code
is mixed up with preprocessor macros (#ifdef TUI), so I think there no
good solution there.

Change-Id: I345175fc7dd865318f0fbe61ac026c88c3b6a96b
---
 gdb/disasm.c       |  2 +-
 gdb/dtrace-probe.c |  2 +-
 gdb/hppa-tdep.c    |  2 +-
 gdb/mips-tdep.c    |  2 +-
 gdb/p-valprint.c   |  2 +-
 gdb/sparc64-tdep.c |  4 ++--
 gdb/tracepoint.c   | 16 ++++++++--------
 7 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/gdb/disasm.c b/gdb/disasm.c
index 3000e5dddad9..5cd1f5adbd22 100644
--- a/gdb/disasm.c
+++ b/gdb/disasm.c
@@ -189,7 +189,7 @@ line_is_less_than (const deprecated_dis_line_entry &mle1,
     {
       if (mle1.start_pc != mle2.start_pc)
 	val = mle1.start_pc < mle2.start_pc;
-    else
+      else
 	val = mle1.line < mle2.line;
     }
   else
diff --git a/gdb/dtrace-probe.c b/gdb/dtrace-probe.c
index 9aeefb6060c4..6f01edf3924c 100644
--- a/gdb/dtrace-probe.c
+++ b/gdb/dtrace-probe.c
@@ -851,7 +851,7 @@ dtrace_static_probe_ops::get_probes
 	  if (bfd_malloc_and_get_section (abfd, sect, &dof) && dof != NULL)
 	    dtrace_process_dof (sect, objfile, probesp,
 				(struct dtrace_dof_hdr *) dof);
-	 else
+	  else
 	    complaint (_("could not obtain the contents of"
 			 "section '%s' in objfile `%s'."),
 		       bfd_section_name (sect), bfd_get_filename (abfd));
diff --git a/gdb/hppa-tdep.c b/gdb/hppa-tdep.c
index 32c543570458..7734115b744c 100644
--- a/gdb/hppa-tdep.c
+++ b/gdb/hppa-tdep.c
@@ -2171,7 +2171,7 @@ hppa_frame_cache (struct frame_info *this_frame, void **this_cache)
 	      fprintf_unfiltered (gdb_stdlog, " (base=%s) [saved]",
 				  paddress (gdbarch, cache->base));
       }
-    else
+     else
       {
 	/* The prologue has been slowly allocating stack space.  Adjust
 	   the SP back.  */
diff --git a/gdb/mips-tdep.c b/gdb/mips-tdep.c
index e5f8c6b20533..1c080bbe50fe 100644
--- a/gdb/mips-tdep.c
+++ b/gdb/mips-tdep.c
@@ -2063,7 +2063,7 @@ micromips_next_pc (struct regcache *regcache, CORE_ADDR pc)
 	  if (regcache_raw_get_signed (regcache, b0s5_reg (insn >> 16))
 		!= regcache_raw_get_signed (regcache, b5s5_reg (insn >> 16)))
 	      pc += micromips_relative_offset16 (insn);
-	    else
+	  else
 	      pc += micromips_pc_insn_size (gdbarch, pc);
 	  break;
 
diff --git a/gdb/p-valprint.c b/gdb/p-valprint.c
index 635d7ed5e4de..a88d6b9a82cd 100644
--- a/gdb/p-valprint.c
+++ b/gdb/p-valprint.c
@@ -313,7 +313,7 @@ pascal_language::value_print_inner (struct value *val,
 	}
       else
 	{
-          if (pascal_is_string_type (type, &length_pos, &length_size,
+	  if (pascal_is_string_type (type, &length_pos, &length_size,
 				     &string_pos, &char_type, NULL) > 0)
 	    {
 	      len = extract_unsigned_integer (valaddr + length_pos,
diff --git a/gdb/sparc64-tdep.c b/gdb/sparc64-tdep.c
index 95d46c83253b..7d9b313783a4 100644
--- a/gdb/sparc64-tdep.c
+++ b/gdb/sparc64-tdep.c
@@ -327,8 +327,8 @@ adi_is_addr_mapped (CORE_ADDR vaddr, size_t cnt)
 	    }
 	}
       }
-    else
-      warning (_("unable to open /proc file '%s'"), filename);
+  else
+    warning (_("unable to open /proc file '%s'"), filename);
 
   return false;
 }
diff --git a/gdb/tracepoint.c b/gdb/tracepoint.c
index 95fc58fb8f06..506af3c527ec 100644
--- a/gdb/tracepoint.c
+++ b/gdb/tracepoint.c
@@ -2410,14 +2410,14 @@ tfind_line_command (const char *args, int from_tty)
 	    error (_("Cannot find a good line."));
 	}
       }
-    else
-      {
-	/* Is there any case in which we get here, and have an address
-	   which the user would want to see?  If we have debugging
-	   symbols and no line numbers?  */
-	error (_("Line number %d is out of range for \"%s\"."),
-	       sal.line, symtab_to_filename_for_display (sal.symtab));
-      }
+  else
+    {
+      /* Is there any case in which we get here, and have an address
+	 which the user would want to see?  If we have debugging
+	 symbols and no line numbers?  */
+      error (_("Line number %d is out of range for \"%s\"."),
+	     sal.line, symtab_to_filename_for_display (sal.symtab));
+    }
 
   /* Find within range of stated line.  */
   if (args && *args)

base-commit: 8d2ef06e1c220bcfb133a47b98b6287ccabdb587
-- 
2.34.1


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-01-31 17:23 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-31 17:23 [pushed] gdb: fix some clang-tidy readability-misleading-indentation warnings Simon Marchi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).