[clang-format] `Cpp11BracedListStyle` vs `BreakBeforeCloseBracketBracedList` precedence
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
I would like to have to have a space of breathing room in CPP Designated initializers and have multiline designated initializers's closed brace on a new line to not created disbalanced indentation. `Cpp11BracedListStyle` and `BreakBeforeCloseBracketBracedList` achieve this, but if used at the same time, the "multiline designated initializer's closing bracket on a new line" gets overridden.
# Ideal:
`color` initializer has breathing room, `subresourceRange`'s initializer doesn't skip over two spaces of indentation
```cpp
const vk::ClearColorValue color { rainbow.r, rainbow.g, rainbow.b, rainbow.a };
vk::ImageMemoryBarrier const barrier {
.srcAccessMask = vk::AccessFlagBits::eMemoryRead,
.dstAccessMask = vk::AccessFlagBits::eTransferWrite,
.oldLayout = vk::ImageLayout::eUndefined,
.newLayout = vk::ImageLayout::eTransferDstOptimal,
.srcQueueFamilyIndex = vk::QueueFamilyIgnored,
.dstQueueFamilyIndex = vk::QueueFamilyIgnored,
.image = swapchainImage,
.subresourceRange = vk::ImageSubresourceRange {
.aspectMask = vk::ImageAspectFlagBits::eColor,
.baseMipLevel = 0,
.levelCount = 1,
.baseArrayLayer = 0,
.layerCount = 1
}
};
```
# Reality
It's either, or.
### With `Cpp11BracedListStyle`
```yaml
BasedOnStyle: LLVM
IndentWidth: 4
TabWidth: 4
UseTab: Always
ColumnLimit: 0
AllowShortFunctionsOnASingleLine: None
AllowShortBlocksOnASingleLine: Never
Cpp11BracedListStyle: true
SpaceBeforeCpp11BracedList: true
BreakBeforeCloseBracketBracedList: true
```
the multiline designated initializer is correct, but no breathing room in `color`.
```cpp
const vk::ClearColorValue color {rainbow.r, rainbow.g, rainbow.b, rainbow.a};
vk::ImageMemoryBarrier const barrier {
.srcAccessMask = vk::AccessFlagBits::eMemoryRead,
.dstAccessMask = vk::AccessFlagBits::eTransferWrite,
.oldLayout = vk::ImageLayout::eUndefined,
.newLayout = vk::ImageLayout::eTransferDstOptimal,
.srcQueueFamilyIndex = vk::QueueFamilyIgnored,
.dstQueueFamilyIndex = vk::QueueFamilyIgnored,
.image = swapchainImage,
.subresourceRange = vk::ImageSubresourceRange {
.aspectMask = vk::ImageAspectFlagBits::eColor,
.baseMipLevel = 0,
.levelCount = 1,
.baseArrayLayer = 0,
.layerCount = 1
}
};
```
### Without `Cpp11BracedListStyle`
```yaml
BasedOnStyle: LLVM
IndentWidth: 4
TabWidth: 4
UseTab: Always
ColumnLimit: 0
AllowShortFunctionsOnASingleLine: None
AllowShortBlocksOnASingleLine: Never
Cpp11BracedListStyle: false
SpaceBeforeCpp11BracedList: true
BreakBeforeCloseBracketBracedList: true
```
there is breathing room in `color` now, but the multiline designated initializer's closing bracket gets pulled up into the previous line, leaving an unsatisfying "hole" of indentation below.
```cpp
const vk::ClearColorValue color { rainbow.r, rainbow.g, rainbow.b, rainbow.a };
vk::ImageMemoryBarrier const barrier {
.srcAccessMask = vk::AccessFlagBits::eMemoryRead,
.dstAccessMask = vk::AccessFlagBits::eTransferWrite,
.oldLayout = vk::ImageLayout::eUndefined,
.newLayout = vk::ImageLayout::eTransferDstOptimal,
.srcQueueFamilyIndex = vk::QueueFamilyIgnored,
.dstQueueFamilyIndex = vk::QueueFamilyIgnored,
.image = swapchainImage,
.subresourceRange = vk::ImageSubresourceRange {
.aspectMask = vk::ImageAspectFlagBits::eColor,
.baseMipLevel = 0,
.levelCount = 1,
.baseArrayLayer = 0,
.layerCount = 1 }
};
```
This can be fixed by giving the final `.layerCount` a closing comma, but since it's the last member, it shouldn't need one.
Contributor guide
Research direction
Start by reproducing the examples with clang-format using Cpp11BracedListStyle, SpaceBeforeCpp11BracedList, and BreakBeforeCloseBracketBracedList. Locate the clang-format option handling and its formatter tests, then verify that both spacing around single-line braced lists and closing-brace placement for multiline designated initializers work together without requiring a trailing comma.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100