From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8337D3851A98; Wed, 15 Jan 2025 16:51:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8337D3851A98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1736959918; bh=4tmSz9pAxw/ShZdDgvNnnmXmbS+fdVf/Q16KCdvLGwY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CVCDLh9WnmxeE+U/6gXWnH2ujWwOOQ6l1OgnZ8nqBa972QnlPBxD/PXb5XcL9MtSW QbH9YNc8Yk95odXMpjKB32+oiREICGy1o4WOugPYz+jlJi9q50deuM0lurmj/hm84n lmiswlL4gNeBflRS9lnjLTp6l7dvtBkpbSM5oAIE= From: "simon.marchi at polymtl dot ca" To: gdb-prs@sourceware.org Subject: [Bug build/30098] Keep trying clang-format Date: Wed, 15 Jan 2025 16:51:58 +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: simon.marchi at polymtl 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: 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 --- Comment #20 from Simon Marchi --- (In reply to Tom Tromey from comment #17) > Here's a case where the formatter tries to be as concise > as possible, but which IMO negatively affects readability: >=20 > static enum debug_loc_kind > -decode_debug_loc_dwo_addresses (dwarf2_per_cu_data *per_cu, > - dwarf2_per_objfile *per_objfile, > - const gdb_byte *loc_ptr, > - const gdb_byte *buf_end, > - const gdb_byte **new_ptr, > - unrelocated_addr *low, > - unrelocated_addr *high, > - enum bfd_endian byte_order) > +decode_debug_loc_dwo_addresses ( > + dwarf2_per_cu_data *per_cu, dwarf2_per_objfile *per_objfile, > + const gdb_byte *loc_ptr, const gdb_byte *buf_end, const gdb_byte > **new_ptr, > + unrelocated_addr *low, unrelocated_addr *high, enum bfd_endian byte_or= der) > { I do like the first one in this case, because the function name is not too long. But if the function name is longer, the parameter list gets awkwardly pushed to the right hand side with very few columns available. If I use these: PenaltyBreakBeforeFirstCallParameter: 1000 PenaltyBreakOpenParenthesis: 1000 PenaltyReturnTypeOnItsOwnLine: 1000 ... it is close to the original version: static enum debug_loc_kind decode_debug_loc_dwo_addresses (dwarf2_per_cu_data *per_cu, dwarf2_per_objfile *per_objfile, const gdb_byte *loc_ptr, const gdb_byte *buf_end, const gdb_byte **new_ptr, unrelocated_addr *low, unrelocated_addr *high, enum bfd_endian byte_order) The only difference is that it put the "low" parameter next to the "new_ptr" parameter, because it had enough room to do so (if the column limit was greater, there would be more packing). The BinPackParameters option has a new "OnePerLine" enum value in clang-for= mat 20 (it used to be boolean), which means "Put all parameters on the current = line if they fit. Otherwise, put each one on its own line.". It would give exac= tly the existing formatting: static enum debug_loc_kind decode_debug_loc_dwo_addresses (dwarf2_per_cu_data *per_cu, dwarf2_per_objfile *per_objfile, const gdb_byte *loc_ptr, const gdb_byte *buf_end, const gdb_byte **new_ptr, unrelocated_addr *low, unrelocated_addr *high, enum bfd_endian byte_order) But it means that whenever parameters don't fit on a single line, they'll be one per line, for instance: -target_desc *amd64_create_target_description (uint64_t xcr0, bool is_x32, - bool is_linux, bool segments); +target_desc *amd64_create_target_description (uint64_t xcr0, + bool is_x32, + bool is_linux, + bool segments); I don't really care, I would be fine with either style. I think that as humans, we sometimes make artistic choices, sometimes we prefer one per lin= e, sometimes we don't (and it is subjective). Whereas a tool can't really know when you'd prefer one style over the other, we have to choose one. --=20 You are receiving this mail because: You are on the CC list for the bug.=