public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Simon Marchi <simark@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb: fix some clang-tidy readability-misleading-indentation warnings Date: Mon, 31 Jan 2022 17:23:03 +0000 (GMT) [thread overview] Message-ID: <20220131172303.4040F3857815@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=492325c4b78933e41608c53963d29b1f16affd47 commit 492325c4b78933e41608c53963d29b1f16affd47 Author: Simon Marchi <simon.marchi@efficios.com> Date: Mon Jan 31 09:44:46 2022 -0500 gdb: fix some clang-tidy readability-misleading-indentation warnings 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 Diff: --- 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 3000e5dddad..5cd1f5adbd2 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 9aeefb6060c..6f01edf3924 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 32c54357045..7734115b744 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 e5f8c6b2053..1c080bbe50f 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 635d7ed5e4d..a88d6b9a82c 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 95d46c83253..7d9b313783a 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 95fc58fb8f0..506af3c527e 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)
reply other threads:[~2022-01-31 17:23 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220131172303.4040F3857815@sourceware.org \ --to=simark@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).