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>