martin lampacher via llvm-dev
2019-Sep-09 07:04 UTC
[llvm-dev] clang-format behaviour for braced lists indent
Hello, I've introduced clang-format (current version 8.0) to enforce some company coding guideline but I am struggling with list initializers. The formatter works nicely with function declarations and function calls and aligns arguments on break like that: static void someUnitInternalFunction( const uint32 someParameter, uint32 *somePointer, uint32 normalParameter, uint8 anotherParameterLong); uint32 SomeUnitWithSomeVeryLongFunctionName( uint32 parameterOne, uint32 parameterTwo, uint32 parameterThree, uint32 parameterFour) { someUnitInternalFunction( someInternalVariableWithSomeVeryLongName, &yetAnotherInternalVariableLongNameStyle, nowThisNameIsShorter, nowThisNameIsShorter); } This matches the configured continuation indent width. For lists, however, the indent does not match what I've expected: A list that exceeds the configured margin is formatted as following (I'm using Cpp11BracedListStyle: true): static uint8 CddDp83848Reg[] = {CDDDP83848_BMCR_REGISTER, CDDDP83848_BMSR_REGISTER, CDDDP83848_PHYIDR1_REGISTER, CDDDP83848_PHYIDR2_REGISTER, CDDDP83848_PHYSTS_REGISTER, CDDDP83848_RBR_REGISTER}; Whereas I'd expect it the following style: static uint8 CddDp83848Reg[] = { CDDDP83848_BMCR_REGISTER, CDDDP83848_BMSR_REGISTER, CDDDP83848_PHYIDR1_REGISTER, CDDDP83848_PHYIDR2_REGISTER, CDDDP83848_PHYSTS_REGISTER, CDDDP83848_RBR_REGISTER}; According to the documentation Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place. If the braced list follows a name (e.g. a type or variable name), clang-format formats as if the {} were the parentheses of a function call with that name. If there is no name, a zero-length name is assumed. And I have the following setting: ContinuationIndentWidth: 4. As you can see the function call is formatted nicely whereas the list initializer isn't, according to the documentation the formatting should be the same. Can someone please help me out here? I've checked several settings and can't make clang-format indent initializers according to the (admittedly a bit special) style. Thanks and BR, Martin Attached demo file and clang-format settings -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/c227636c/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT11905.clang-format Type: application/octet-stream Size: 3908 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/c227636c/attachment.obj> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/c227636c/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: SomeUnit.c Type: application/octet-stream Size: 2363 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/c227636c/attachment-0001.obj> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/c227636c/attachment-0002.html>
Shoaib Meenai via llvm-dev
2019-Sep-09 15:22 UTC
[llvm-dev] clang-format behaviour for braced lists indent
(forwarding this to cfe-dev and BCC'ing llvm-dev, since cfe-dev is a better place for clang-format queries) From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of martin lampacher via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: martin lampacher <lmapii at googlemail.com> Date: Monday, September 9, 2019 at 12:04 AM To: LLVM Development List <llvm-dev at lists.llvm.org> Subject: [llvm-dev] clang-format behaviour for braced lists indent Hello, I've introduced clang-format (current version 8.0) to enforce some company coding guideline but I am struggling with list initializers. The formatter works nicely with function declarations and function calls and aligns arguments on break like that: static void someUnitInternalFunction( const uint32 someParameter, uint32 *somePointer, uint32 normalParameter, uint8 anotherParameterLong); uint32 SomeUnitWithSomeVeryLongFunctionName( uint32 parameterOne, uint32 parameterTwo, uint32 parameterThree, uint32 parameterFour) { someUnitInternalFunction( someInternalVariableWithSomeVeryLongName, &yetAnotherInternalVariableLongNameStyle, nowThisNameIsShorter, nowThisNameIsShorter); } This matches the configured continuation indent width. For lists, however, the indent does not match what I've expected: A list that exceeds the configured margin is formatted as following (I'm using Cpp11BracedListStyle: true): static uint8 CddDp83848Reg[] = {CDDDP83848_BMCR_REGISTER, CDDDP83848_BMSR_REGISTER, CDDDP83848_PHYIDR1_REGISTER, CDDDP83848_PHYIDR2_REGISTER, CDDDP83848_PHYSTS_REGISTER, CDDDP83848_RBR_REGISTER}; Whereas I'd expect it the following style: static uint8 CddDp83848Reg[] = { CDDDP83848_BMCR_REGISTER, CDDDP83848_BMSR_REGISTER, CDDDP83848_PHYIDR1_REGISTER, CDDDP83848_PHYIDR2_REGISTER, CDDDP83848_PHYSTS_REGISTER, CDDDP83848_RBR_REGISTER}; According to the documentation Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place. If the braced list follows a name (e.g. a type or variable name), clang-format formats as if the {} were the parentheses of a function call with that name. If there is no name, a zero-length name is assumed. And I have the following setting: ContinuationIndentWidth: 4. As you can see the function call is formatted nicely whereas the list initializer isn't, according to the documentation the formatting should be the same. Can someone please help me out here? I've checked several settings and can't make clang-format indent initializers according to the (admittedly a bit special) style. Thanks and BR, Martin Attached demo file and clang-format settings -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/8485e30a/attachment.html>