From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8D7943858D20; Wed, 8 Feb 2023 20:32:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8D7943858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675888327; bh=ArxHYNmSaYnpuUONMlmBIfgpMsFpa8zSLU1usPcyHtU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=olHt5uUO08pXtwiaVjMYXj2PxcfH5bxawMssyMbdZj0ufXUnb+z45TMy6KhygYxh8 jYMTYmnq/rFT6luwXQQN8OmcVrWDvvxR6tvSyaiTceE/EwM3Tc69Zp5ADvX1X5qke+ GFWlScV5dpcJh2uNrcRK/Lbayx8NF4pCUlbtnZCA= From: "simark at simark dot ca" To: gdb-prs@sourceware.org Subject: [Bug build/30098] Keep trying clang-format Date: Wed, 08 Feb 2023 20:32:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: build X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: simark at simark dot ca X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30098 Simon Marchi changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simark at simark dot ca --- Comment #6 from Simon Marchi --- Thanks for filing this. Can we make some branch on sourceware with the latest attempt at doing this, that we could update over time? I would suggest to have just two commits o= ver master, one commit to add .clang-format (and maybe a script to run clang-fo= rmat correctly to do a mass reformat) and another commit that is the actual mass reformat. Using clang-format-15, I see some changes that are not stable in hppa-netbsd-tdep.c, clang-format changes the code every time I run it: diff --git a/gdb/hppa-netbsd-tdep.c b/gdb/hppa-netbsd-tdep.c index 5468a135caf7..7b4c8c71fe2f 100644 --- a/gdb/hppa-netbsd-tdep.c +++ b/gdb/hppa-netbsd-tdep.c @@ -63,30 +63,29 @@ static void hppanbsd_sigtramp_cache_init (const struct tramp_frame *, struct trad_frame_cache *, CORE_ADDR); -static const struct tramp_frame hppanbsd_sigtramp_si4 =3D { - SIGTRAMP_FRAME, - 4, - { { 0xc7d7c012, ULONGEST_MAX }, /* bb,>=3D,n %arg3, 30, 1f */ - { 0xd6e01c1e, ULONGEST_MAX }, /* depwi 0,31,2,%arg3 */ - { 0x0ee81093, ULONGEST_MAX }, /* ldw 4(%arg3), %r19 */ - { 0x0ee01097, ULONGEST_MAX }, /* ldw 0(%arg3), %arg3 */ - /* 1: */ - { 0xe8404000, ULONGEST_MAX }, /* blr %r0, %rp */ - { 0xeae0c002, ULONGEST_MAX }, /* bv,n %r0(%arg3) */ - { 0x08000240, ULONGEST_MAX }, /* nop */ - - { 0x0803025a, ULONGEST_MAX }, /* copy %r3, %arg0 */ - { 0x20200801, ULONGEST_MAX }, /* ldil -40000000, %r1 */ - { 0xe420e008, ULONGEST_MAX }, /* be,l 4(%sr7, %r1), %sr0, %r31 */ - { 0x34160268, ULONGEST_MAX }, /* ldi 134, %t1 ; SYS_setcontext */ - - { 0x081c025a, ULONGEST_MAX }, /* copy ret0, %arg0 */ - { 0x20200801, ULONGEST_MAX }, /* ldil -40000000, %r1 */ - { 0xe420e008, ULONGEST_MAX }, /* be,l 4(%sr7, %r1), %sr0, %r31 */ - { 0x34160002, ULONGEST_MAX }, /* ldi 1, %t1 ; SYS_exit */ - { TRAMP_SENTINEL_INSN, ULONGEST_MAX } }, - hppanbsd_sigtramp_cache_init -}; +static const struct tramp_frame hppanbsd_sigtramp_si4 + =3D { SIGTRAMP_FRAME, + 4, + { { 0xc7d7c012, ULONGEST_MAX }, /* bb,>=3D,n %arg3, 30, 1f=20= =20=20=20=20=20=20=20=20=20 */ + { 0xd6e01c1e, ULONGEST_MAX }, /* depwi 0,31,2,%arg3=20=20= =20=20=20=20=20=20=20=20=20=20 */ + { 0x0ee81093, ULONGEST_MAX }, /* ldw 4(%arg3), %r19=20=20=20= =20=20=20=20=20=20=20=20=20=20 */ + { 0x0ee01097, ULONGEST_MAX }, /* ldw 0(%arg3), %arg3=20=20= =20=20=20=20=20=20=20=20=20=20 */ + /* 1: */ + { 0xe8404000, ULONGEST_MAX }, /* blr %r0, %rp=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 */ + { 0xeae0c002, ULONGEST_MAX }, /* bv,n %r0(%arg3)=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 */ + { 0x08000240, ULONGEST_MAX }, /* nop=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 */ + + { 0x0803025a, ULONGEST_MAX }, /* copy %r3, %arg0=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 */ + { 0x20200801, ULONGEST_MAX }, /* ldil -40000000, %r1=20=20= =20=20=20=20=20=20=20=20=20=20 */ + { 0xe420e008, ULONGEST_MAX }, /* be,l 4(%sr7, %r1), %sr0, %r= 31=20=20 */ + { 0x34160268, ULONGEST_MAX }, /* ldi 134, %t1 ; SYS_setcont= ext=20 */ + + { 0x081c025a, ULONGEST_MAX }, /* copy ret0, %arg0=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 */ + { 0x20200801, ULONGEST_MAX }, /* ldil -40000000, %r1=20=20= =20=20=20=20=20=20=20=20=20=20 */ + { 0xe420e008, ULONGEST_MAX }, /* be,l 4(%sr7, %r1), %sr0, %r= 31=20=20 */ + { 0x34160002, ULONGEST_MAX }, /* ldi 1, %t1 ; SYS_exit=20= =20=20=20=20=20=20=20=20 */ + { TRAMP_SENTINEL_INSN, ULONGEST_MAX } }, + hppanbsd_sigtramp_cache_init }; Probably a bug in clang-format? I guess that could be worked around by pla= cing markers around that code to prevent clang-format from touching it. In my .clang-format, I had `UseTab: Always`, but it doesn't seem to make a difference compared to what you have. > Sometimes clang-format makes bad decisions. One example > I'm looking at is if you have an 'if' that is a series of > clauses joined by '&&', sometimes it is clearest to put > each such clause on its own line. However clang-format does this: >=20 > @@ -194,10 +193,8 @@ eq_bfd (const void *a, const void *b) > =3D (const struct gdb_bfd_cache_search *) b; > struct gdb_bfd_data *gdata =3D (struct gdb_bfd_data *) bfd_usrdata (ab= fd); >=20=20 > - return (gdata->mtime =3D=3D s->mtime > - && gdata->size =3D=3D s->size > - && gdata->inode =3D=3D s->inode > - && gdata->device_id =3D=3D s->device_id > + return (gdata->mtime =3D=3D s->mtime && gdata->size =3D=3D s->size > + && gdata->inode =3D=3D s->inode && gdata->device_id =3D=3D s->device_= id > && strcmp (bfd_get_filename (abfd), s->filename) =3D=3D 0); > } I agree that the old one is more readable. I suppose that could be a clang-format rule, similar to BinPackParameters. If an expression fits on = one line, leave it on one line. Otherwise, break at binary operators. It could happen with other operators too, like: something =3D (aaaaaaaa + bbbbbbbb + cccccccc + dddddddd);=20 vs something =3D (aaaaaaaa + bbbbbbbb + cccccccc + dddddddd); Of course, humans will pretty much always make better decisions for things = like this. For instance, you might want to have it organized logically like thi= s: path =3D (base + "/" + subdir1 + "/" + subdir2 + "/" + subdir3); But the tool will either choose: path =3D (base + "/" + subdir1 + "/" + subdir2 + "/" + subdir3); of path =3D (base + "/" + subdir1 + "/" + subdir2 + "/" + subdir3); If we want to use an automated tool, we have to accept the tradeoff that so= me cases will be less nice, in exchange for convenience. --=20 You are receiving this mail because: You are on the CC list for the bug.=