[clang-format] Add BracedInitializerIndentWidth option.

[jp4a50]

Summary

The option allows users to specify how many columns to use to indent
the contents of initializer lists.

This addresses the corresponding github issue, albeit in a slightly different and broader way to what was proposed there.

[jp4a50]

Apply clang-format.

[jp4a50]

clang/docs/ClangFormatStyleOptions.rst

2739

Perhaps it would be better to make this a signed integer and default to -1 which would cause ContinuationIndentWidth to be used (i.e. current behaviour)?

[MyDeveloperDay]

clang/include/clang/Format/Format.h

2064

Endcode

clang/lib/Format/Format.cpp

910

Needs a parse test

clang/unittests/Format/FormatTest.cpp

4861

Can we fix the brace positioning too

[owenpan]

Please see https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options. Is there a way to fix the issue without adding a new option?

[MyDeveloperDay]

clang/lib/Format/Format.cpp

1379

so lets say someone is using an IndentWidth of 2 and now you introduce this as being 4 here as the default

Without them changing anything, all their DesignatedIntializer code will get refactored to a IndentWidth of 4 rather than the 2 it was previously

This is where we get called out for "changing the defaults", which really we are not we are just reclassifying how it behaves.

What we normally say here is can you point us to a public style that has an independent DesignatedIntializerIndentWidth which is independent from the levels of IndentWidth everywhere else.

Whilst I can see more knobs feels good, this will change code and we'll have to manage that expectation.

[jp4a50]

clang/lib/Format/Format.cpp

1379

Yep, so as per my comment in clang/docs/ClangFormatStyleOptions.rst I think I am changing my mind about this anyway.

My motivation for making this change is to support the KJ style guide which is quoted in the github issue - I work on a team that uses the KJ style guide.

The KJ style guide wants a designated initializer indent width of 2 along with a "normal" indent width of 2, so there is no explicit need for us to have those two values be different.

When originally making these changes, I did think that having "more knobs" was a good idea, but I agree that this could lead to annoying behaviour for some users and they would probably expect the designated initializer indent to match either the normal indent or the continuation indent.

How about I change the option to an integer and, when it's -1 (the default), the designated initializer indent matches the continuation indent, but if it is set to a value >= 0 then that number of columns is used instead?

clang/unittests/Format/FormatTest.cpp

4861

What would you expect the brace positioning to be here? I noticed that, with this configuration at least, the closing brace goes at the end of the same line (as the last initializer) when there is no trailing comma but goes on a new line if there is a trailing comma.

[jp4a50]

Change DesignatedInitializerIndentWidth to a signed integer which defaults to ContinuationIndentWidth when set to -1.

[jp4a50]

clang/lib/Format/Format.cpp

1379

I've reimplemented the option as a signed integer as per my suggestion above.

[jp4a50]

In D146101#4195293, @owenpan wrote:

Please see https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options. Is there a way to fix the issue without adding a new option?

@owenpan We could simply change the indentation level of designated initializers for everyone to match IndentWidth instead of ContinuationIndentWidth but I suspect that other users might be unhappy if we made that breaking change? I guess we could also consider making this behaviour only kick in when a specific set of *other* options are specified (e.g. AlwaysBreak) so that it applies to our clang-format style and not *all* others but that just feels like a hack.

I understand the added complexity and maintenance burden of a new option but we do meet the 3 criteria listed in your link.

• it is part of the KJ style guide which is used by the capn proto project which has over 100 maintainers
• the style guide is publicly accessible here
• I'm willing to contribute and maintain patches :)

I think it's also worth noting that the google style guide gives an example of designated initializers indented at 2 spaces (whereas their "continuation indent" for wrapped function parameters is 4).

[owenpan]

In D146101#4201842, @jp4a50 wrote:

I understand the added complexity and maintenance burden of a new option but we do meet the 3 criteria listed in your link.

• it is part of the KJ style guide which is used by the capn proto project which has over 100 maintainers
• the style guide is publicly accessible here

The style guide doesn't mention indenting designated initializers with 2 spaces?

• I'm willing to contribute and maintain patches :)

I think it's also worth noting that the google style guide gives an example of designated initializers indented at 2 spaces (whereas their "continuation indent" for wrapped function parameters is 4).

It's likely an error that the designated initializer example there shows 2-space indents as clang-format uses the 4-space continuation indent width:

clang-format -style=Google
Point p = {
    .x = 1.0, .y = 2.0,
    // z will be 0.0
};
Point p = {
    .x = 1.0, .y = 2.0,
    // z will be 0.0
};

[jp4a50]

The style guide doesn't mention indenting designated initializers with 2 spaces?

That is a fair point. I will get it updated because the author and maintainer of that style guide is the one requesting this change since, in practice, codebases following this style guide indent designated initializers with 2 spaces.

I think it's also worth noting that the google style guide gives an example of designated initializers indented at 2 spaces (whereas their "continuation indent" for wrapped function parameters is 4).

It's likely an error that the designated initializer example there shows 2-space indents as clang-format uses the 4-space continuation indent width:

This is possible, but isn't it also possible that they would prefer designated initializers to be indented at 2 spaces but don't have the option with clang-format currently?

The only general information supplied in the google style guide about indentation is as follows:

• Default indentation is 2 spaces.
• Wrapped parameters have a 4 space indent.

If we are taking a strict definition of parameters, the above suggests to me that designated initializers would fall under the default indentation of 2 spaces.

As mentioned on my other diff, I'm away until next Monday now so won't be able to get back to further comments til then.

[MyDeveloperDay]

What I'd really like to see, is... in the event that ContinuationIndentWidth is set and I do NOTset DesignatedInitializerIndentWidth , then DesignatedInitializerIndentWidth would inherit from that (not the default as you have here), if I set ContinuationIndentWidthto 3 DesignatedInitializerIndentWidth should be 3

Otherwise if I set DesignatedInitializerIndentWidth explicitly then it can be what is set,

i.e. (for base LLVM style)

ContinuationIndentWidth is not set = (default) 4
DesignatedInitializerIndentWidth = not set  (implicitly 4)

ContinuationIndentWidth is set = 3
DesignatedInitializerIndentWidth = not set  (implicitly 3)

ContinuationIndentWidth is not set = (default) 4
DesignatedInitializerIndentWidth = is set to 2  (explicitly 2)

ContinuationIndentWidth is set = 3
DesignatedInitializerIndentWidth = is set to 4 (explicitly 4)

clang/unittests/Format/FormatTest.cpp

4861

part of me would like an option to not have to supply the trailing comma,

[jp4a50]

In D146101#4208962, @MyDeveloperDay wrote:

What I'd really like to see, is... in the event that ContinuationIndentWidth is set and I do NOTset DesignatedInitializerIndentWidth , then DesignatedInitializerIndentWidth would inherit from that (not the default as you have here), if I set ContinuationIndentWidthto 3 DesignatedInitializerIndentWidth should be 3

Agree that this makes the most sense and, luckily, that is exactly the behaviour I implemented in my most recent diff!

[owenpan]

In D146101#4204653, @jp4a50 wrote:

I think it's also worth noting that the google style guide gives an example of designated initializers indented at 2 spaces (whereas their "continuation indent" for wrapped function parameters is 4).

It's likely an error that the designated initializer example there shows 2-space indents as clang-format uses the 4-space continuation indent width:

This is possible, but isn't it also possible that they would prefer designated initializers to be indented at 2 spaces but don't have the option with clang-format currently?

I really doubt it as the creators of clang-format and a number of reviewers/contributors/maintainers from the recent past were Google engineers, I believe.

The only general information supplied in the google style guide about indentation is as follows:

• Default indentation is 2 spaces.
• Wrapped parameters have a 4 space indent.

If we are taking a strict definition of parameters, the above suggests to me that designated initializers would fall under the default indentation of 2 spaces.

IMO it's clear that in Google style IndentWidth = 2 and ContinuationIndentWidth = 4. I think in general IndentWidth is for block indent and ContinuationIndentWidth is for everything else.

clang/lib/Format/ContinuationIndenter.cpp

1665

Can you also move it into the else if below to reduce the scope of the pointer? Please note the typo NextNoComment.

1670–1674

Using -1 to mean ContinuationIndentWidth is unnecessary and somewhat confusing IMO.

[owenpan]

clang/include/clang/Format/Format.h

2070

clang/lib/Format/Format.cpp

1379

clang/unittests/Format/ConfigParseTest.cpp

252–253

Delete.

clang/unittests/Format/FormatTest.cpp

4878

Delete it and rearrange the tests so that the unspecified (default) DesignatedInitializerIndentWidth is tested first.

[owenpan]

clang/include/clang/Format/Format.h

2070

Please disregard my comment above.

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

Please disregard my comment above.

clang/lib/Format/Format.cpp

1379

Please disregard my comment above.

clang/unittests/Format/ConfigParseTest.cpp

252–253

Please disregard my comment above.

clang/unittests/Format/FormatTest.cpp

4878

Please disregard my comment above.

[owenpan]

clang/include/clang/Format/Format.h

2058

2070

Please add \version 17.

clang/lib/Format/ContinuationIndenter.cpp

1665

Please ignore my comment above.

[jp4a50]

Address minor review comments.

[jp4a50]

All actionable comments have been addressed.

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

Just to make sure we are on the same page, does this mean that you are happy with the approach of using -1 as a default value to indicate that ContinuationIndentWidth should be used?

I did initially consider using std::optional<unsigned> and using empty optional to indicate that ContinuationIndentWidth should be used but I saw that PPIndentWidth was using -1 to default to using IndentWidth so I followed that precedent.

clang/unittests/Format/FormatTest.cpp

4861

I agree that it's slightly odd behaviour but I think it's pretty orthogonal to this change and would deserve it's own diff.

I think it's also pretty debatable what the behaviour *should* be. Should the AlignAfterOpenBracket option dictate the formatting of braces like this? Oddly enough, specifying AlwaysBreak (as I have done in this test) does indeed result in breaking after the { but changing it to BlockIndent doesn't put the closing } on a newline. Should we instead add a new AlignAfterOpenBrace analogue of AlignAfterOpenBracket?

Would you like me to to raise a separate issue to track this (if it doesn't already exist)?

[owenpan]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

Yep! I would prefer the optional, but as you pointed out, we already got PPIndentWidthusing -1.

[HazardyKnusperkeks]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

From the C++ side I totally agree. One could use value_or(), which would make the code much more readable.
And just because PPIndentWidth is using -1 is no reason to repeat that, we could just as easily change PPIndentWidht to an optional.

But how would it look in yaml?

[jp4a50]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

In YAML we wouldn't need to support empty optional being *explicitly* specified - it would just be the default.

So specifying DesignatedInitializerIndentWidth: 4 would set the std::optional<unsigned> to 4 but if DesignatedInitializerIndentWidth was omitted from the YAML then the optional would simply not be set during parsing.

Of course, if we were to change PPIndentWidth to work that way too, it would technically be a breaking change because users may have *explicitly* specified -1 in their YAML.

[owenpan]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

And just because PPIndentWidth is using -1 is no reason to repeat that, we could just as easily change PPIndentWidht to an optional.

We would have to deal with backward compatibility to avoid regressions though.

[HazardyKnusperkeks]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

In YAML we wouldn't need to support empty optional being *explicitly* specified - it would just be the default.

So specifying DesignatedInitializerIndentWidth: 4 would set the std::optional<unsigned> to 4 but if DesignatedInitializerIndentWidth was omitted from the YAML then the optional would simply not be set during parsing.

Of course, if we were to change PPIndentWidth to work that way too, it would technically be a breaking change because users may have *explicitly* specified -1 in their YAML.

You need an explicit entry, because you need to be able to write the empty optional on --dump-config.

[jp4a50]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

In YAML we wouldn't need to support empty optional being *explicitly* specified - it would just be the default.

So specifying DesignatedInitializerIndentWidth: 4 would set the std::optional<unsigned> to 4 but if DesignatedInitializerIndentWidth was omitted from the YAML then the optional would simply not be set during parsing.

Of course, if we were to change PPIndentWidth to work that way too, it would technically be a breaking change because users may have *explicitly* specified -1 in their YAML.

You need an explicit entry, because you need to be able to write the empty optional on --dump-config.

It looks like the YAML IO logic just does the right thing (TM) with std::optionals. When calling IO.mapOptional() on output, it simply doesn't write the key out if the value is an empty optional. So I don't think this is an issue.

As @owenpan says, though, there is still the issue of backward compatibility with PPIndentWidth.

I don't feel strongly about which way to go so I'll leave it to you two to decide!

[owenpan]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

As @owenpan says, though, there is still the issue of backward compatibility with PPIndentWidth.

I don't feel strongly about which way to go so I'll leave it to you two to decide!

@MyDeveloperDay @rymiel can you weigh in?

[rymiel]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

can you weigh in?

Well, as someone with experience with YAML, but with no experience with LLVM's YAML stuff, I'd suggest making it null (explicitly), but a) i don't know if that's supported and b) i'm not sure if it's semantically any clearer than just -1

[MyDeveloperDay]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

I'd do the right think with DesignatedInitializerIndentWidth which I guess is to use the std::optional that @owenpan suggests and don't worry about PPIndentWidth for now,

if anything if it works I'd prefer to understand if we can turn PPIndentWidth into a std::optional later (in a seperate review) and just catch the -1 case so at least the code is nicer, but that is a different task

[jp4a50]

So at the risk of adding to the number of decisions we need to come to a consensus on, I was about to update the KJ style guide to explicitly call out the difference in indentation for designated initializers when I realized that we (both KJ code authors and clang-format contributors) should consider whether users should have the option to configure other similar types of indentation following opening braces.

I chatted to the owner of the KJ style guide and, whilst he did not have extremely strong opinions one way or another, he and I agreed that it probably makes more sense for such a config option to apply to other types of braced init lists.

Broadly speaking, these include aggregate initialization and list initialization (possibly direct initialization with braces too). See the initialization cppref article for links to all these.

As such, I would propose to actually rename DesignatedInitializerIndentWidth to BracedInitializerIndentWidth (but open to suggestiosn on exact naming) and have it apply to all the above types of initialization.

What does everyone think?

[HazardyKnusperkeks]

In D146101#4233535, @jp4a50 wrote:

So at the risk of adding to the number of decisions we need to come to a consensus on, I was about to update the KJ style guide to explicitly call out the difference in indentation for designated initializers when I realized that we (both KJ code authors and clang-format contributors) should consider whether users should have the option to configure other similar types of indentation following opening braces.

I chatted to the owner of the KJ style guide and, whilst he did not have extremely strong opinions one way or another, he and I agreed that it probably makes more sense for such a config option to apply to other types of braced init lists.

Broadly speaking, these include aggregate initialization and list initialization (possibly direct initialization with braces too). See the initialization cppref article for links to all these.

As such, I would propose to actually rename DesignatedInitializerIndentWidth to BracedInitializerIndentWidth (but open to suggestiosn on exact naming) and have it apply to all the above types of initialization.

What does everyone think?

Would be okay for me. But then I want the documentation and tests show nested initialization (array of struct for example).

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

In YAML we wouldn't need to support empty optional being *explicitly* specified - it would just be the default.

So specifying DesignatedInitializerIndentWidth: 4 would set the std::optional<unsigned> to 4 but if DesignatedInitializerIndentWidth was omitted from the YAML then the optional would simply not be set during parsing.

Of course, if we were to change PPIndentWidth to work that way too, it would technically be a breaking change because users may have *explicitly* specified -1 in their YAML.

You need an explicit entry, because you need to be able to write the empty optional on --dump-config.

It looks like the YAML IO logic just does the right thing (TM) with std::optionals. When calling IO.mapOptional() on output, it simply doesn't write the key out if the value is an empty optional. So I don't think this is an issue.

As @owenpan says, though, there is still the issue of backward compatibility with PPIndentWidth.

I don't feel strongly about which way to go so I'll leave it to you two to decide!

As @MyDeveloperDay said, ignore PPIndentWidth, that will be dealt with on a different occasion. Use the optional, it is the right thing (TM) to do.
For the yaml stuff, I for one like to define everything (even it has the default value), thus I'd like the -1 or something on output. But if that leads to messing around with the yaml code just use what it does.

[owenpan]

In D146101#4233535, @jp4a50 wrote:

Broadly speaking, these include aggregate initialization and list initialization (possibly direct initialization with braces too). See the initialization cppref article for links to all these.

As such, I would propose to actually rename DesignatedInitializerIndentWidth to BracedInitializerIndentWidth (but open to suggestiosn on exact naming) and have it apply to all the above types of initialization.

What does everyone think?

+1.

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

I'd do the right think with DesignatedInitializerIndentWidth which I guess is to use the std::optional that @owenpan suggests and don't worry about PPIndentWidth for now

+1.

[jp4a50]

Replace DesignatedInitializerIndentWidth with BracedInitializerIndentWidth which applies to a broader range of initializers.

[jp4a50]

I've implemented BracedInitializerIndentWidth now with significantly extended test coverage (including checking that it is not applied *too* broadly). The actual implementation is just as simple as that for DesignatedInitializerIndentWidth.

For the yaml stuff, I for one like to define everything (even it has the default value), thus I'd like the -1 or something on output. But if that leads to messing around with the yaml code just use what it does.

Pretty sure I would have to modify the YAML code in order to get it to output something when std::optional<unsigned> is set to std::nullopt so I have left it as-is.

PTAL.

[jp4a50]

clang/docs/tools/dump_format_style.py

72–78

I changed this from subn to match here since it's just a simpler way of expressing the same thing.

[MyDeveloperDay]

clang/include/clang/Format/Format.h

949

did you check generating the html from the rst? I can never remember if we need a newline before the \code

4341

can this be alphabetic

clang/lib/Format/Format.cpp

910

also alphabetic

1379

ditto alphabetic

[rymiel]

clang/docs/tools/dump_format_style.py

72–78

(Just FYI, those pythons sources are pretty ancient and untouched, I planned on refactoring the whole thing using more modern, idiomatic Python but then concluded that it's not really necessary)

[jp4a50]

clang/include/clang/Format/Format.h

949

Nope - how do I do that exactly? I would guess a newline is not needed based on other examples.

[jp4a50]

Alphabetical ordering.

[HazardyKnusperkeks]

clang/include/clang/Format/Format.h

949

did you check generating the html from the rst? I can never remember if we need a newline before the \code

clang/lib/Format/ContinuationIndenter.cpp

1665

Why did you move it?

1669–1673

You can keep the local variable if you want, but please use value_or, it expresses the intent better.

[owenpan]

clang/include/clang/Format/Format.h

949

Nope - how do I do that exactly? I would guess a newline is not needed based on other examples.

See D147327#4236718.

[jp4a50]

Minor review comments.

[jp4a50]

clang/include/clang/Format/Format.h

949

HTML looks good.

clang/lib/Format/ContinuationIndenter.cpp

1665

I originally needed it in the new else if block since I was checking if it was a designated initializer period but the condition has since changed. Thanks for spotting. I've moved it back.

1669–1673

Have used .value_or() and got rid of temp variable since it's more concise now.

[jp4a50]

Following on from our discussion about new options needing motivation from public style guides, I've updated the KJ style guide to clarify its stance on braced init lists: https://github.com/capnproto/capnproto/blob/master/style-guide.md#spacing-and-bracing

[jp4a50]

Just FYI this is ready for review again. I believe I've addressed all comments.

[MyDeveloperDay]

Can you mark your comments as done

[jp4a50]

Marked comments as done.

[sstwcw]

clang/docs/tools/dump_format_style.py

72–78

Is curdeius the one who knows about the Python scripts and the YAML parser? Did he move on to meaningful things?

[jp4a50]

Ping for review again plz.

[MyDeveloperDay]

If all comments and concerns are done, then I'm inclined to accept, but I'd like @owenpan and @HazardyKnusperkeks to give their opinion before we land this.

[jp4a50]

In D146101#4261293, @MyDeveloperDay wrote:

If all comments and concerns are done, then I'm inclined to accept, but I'd like @owenpan and @HazardyKnusperkeks to give their opinion before we land this.

Sure. Thanks!

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

In YAML we wouldn't need to support empty optional being *explicitly* specified - it would just be the default.

So specifying DesignatedInitializerIndentWidth: 4 would set the std::optional<unsigned> to 4 but if DesignatedInitializerIndentWidth was omitted from the YAML then the optional would simply not be set during parsing.

Of course, if we were to change PPIndentWidth to work that way too, it would technically be a breaking change because users may have *explicitly* specified -1 in their YAML.

You need an explicit entry, because you need to be able to write the empty optional on --dump-config.

It looks like the YAML IO logic just does the right thing (TM) with std::optionals. When calling IO.mapOptional() on output, it simply doesn't write the key out if the value is an empty optional. So I don't think this is an issue.

As @owenpan says, though, there is still the issue of backward compatibility with PPIndentWidth.

I don't feel strongly about which way to go so I'll leave it to you two to decide!

As @MyDeveloperDay said, ignore PPIndentWidth, that will be dealt with on a different occasion. Use the optional, it is the right thing (TM) to do.
For the yaml stuff, I for one like to define everything (even it has the default value), thus I'd like the -1 or something on output. But if that leads to messing around with the yaml code just use what it does.

@HazardyKnusperkeks @owenpan, before potentially committing this change, I just wanted to draw your attention again to this comment to confirm that you are happy with the current implementation which doesn't explicitly print null or similar for a default value of DesignatedInitializerIndentWidth when dumping the config. I'm assuming that's OK since @HazardyKnusperkeks suggested that we don't bother if it involves messing around with the yaml code (which it would).

[HazardyKnusperkeks]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

@HazardyKnusperkeks @owenpan, before potentially committing this change, I just wanted to draw your attention again to this comment to confirm that you are happy with the current implementation which doesn't explicitly print null or similar for a default value of DesignatedInitializerIndentWidth when dumping the config. I'm assuming that's OK since @HazardyKnusperkeks suggested that we don't bother if it involves messing around with the yaml code (which it would).

Sure, everything is fine.

[owenpan]

clang/lib/Format/ContinuationIndenter.cpp

1670–1674

Looks good.

[jp4a50]

Commit details as follows as per other diffs:

Name: Jon Phillips
Email: [e-mail]

Would appreciate someone committing for me.

[owenpan]

In D146101#4268487, @jp4a50 wrote:

Would appreciate someone committing for me.

Can you rebase it? I got a conflict in ReleaseNotes.rst.

[jp4a50]

Rebase.

[jp4a50]

In D146101#4270509, @owenpan wrote:

In D146101#4268487, @jp4a50 wrote:

Would appreciate someone committing for me.

Can you rebase it? I got a conflict in ReleaseNotes.rst.

@owenpan apologies for the delay. I've rebased now.

[owenpan]

@jp4a50 There's a mismatch between Format.h and and the resulting rst file. I'll rerun dump_format_style.py to fix it before merging.

clang/docs/ClangFormatStyleOptions.rst

* ``bool SplitEmptyNamespace`` If ``false``, empty namespace body can be put on a single line.
     .. code-block:: c++
 
       false:               true:
       namespace Foo   vs.  namespace Foo
       {}                   {
                            }
 
 
+.. _BracedInitializerIndentWidth:
+
+**BracedInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 17` :ref:`¶ <BracedInitializerIndentWidth>`
+  The number of columns to use to indent the contents of braced init lists.
+  If unset, ``ContinuationIndentWidth`` is used.
+
+  .. code-block:: c++
+
+    AlignAfterOpenBracket: AlwaysBreak
+    BracedInitializerIndentWidth: 2
+
+    void f() {
+      SomeClass c{
+        "foo",
+        "bar",
+        "baz",
+      };
+      auto s = SomeStruct{
+        .foo = "foo",
+        .bar = "bar",
+        .baz = "baz",
+      };
+      SomeArrayT a[3] = {
+        {
+          foo,
+          bar,
+        },
+        {
+          foo,
+          bar,
+        },
+        SomeArrayT{},
+      };
+    }
+
 .. _BreakAfterAttributes:
 
 **BreakAfterAttributes** (``AttributeBreakingStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakAfterAttributes>`
   Break after a group of C++11 attributes before a function
   declaration/definition name.
 
   Possible values:
 
**DerivePointerAlignment** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DerivePointerAlignment>`
   If ``true``, analyze the formatted file for the most common
   alignment of ``&`` and ``*``.
   Pointer and reference alignment styles are going to be updated according
   to the preferences found in the file.
   ``PointerAlignment`` is then used only as fallback.
 
 .. _DisableFormat:
 
 **DisableFormat** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DisableFormat>`
   Disables formatting completely.
 
 .. _EmptyLineAfterAccessModifier:
 
 **EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``) :versionbadge:`clang-format 13` :ref:`¶ <EmptyLineAfterAccessModifier>`
   Defines when to put an empty line after access modifiers.
   ``EmptyLineBeforeAccessModifier`` configuration handles the number of
   empty lines between two access modifiers.

clang/docs/ReleaseNotes.rst

 
 - Add ``NextLineOnly`` style to option ``PackConstructorInitializers``.
   Compared to ``NextLine`` style, ``NextLineOnly`` style will not try to
   put the initializers on the current line first, instead, it will try to
   put the initializers on the next line only.
 - Add additional Qualifier Ordering support for special cases such
   as templates, requires clauses, long qualified names.
 - Fix all known issues associated with ``LambdaBodyIndentation: OuterScope``.
+- Add ``BracedInitializerIndentWidth`` which can be used to configure
+  the indentation level of the contents of braced init lists.
 
 libclang
 --------
 
 - Introduced the new function ``clang_CXXMethod_isExplicit``,
   which identifies whether a constructor or conversion function cursor
   was marked with the explicit identifier.
 

clang/docs/tools/dump_format_style.py

if typestr == 'bool':
     return 'Boolean'
   elif typestr == 'int':
     return 'Integer'
   elif typestr == 'unsigned':
     return 'Unsigned'
   elif typestr == 'std::string':
     return 'String'
 
-  subtype, napplied = re.subn(r'^std::vector<(.*)>$', r'\1', typestr)
-  if napplied == 1:
-    return 'List of ' + pluralize(to_yaml_type(subtype))
+  match = re.match(r'std::vector<(.*)>$', typestr)
+  if match:
+    return 'List of ' + pluralize(to_yaml_type(match.group(1)))
+
+  match = re.match(r'std::optional<(.*)>$', typestr)
+  if match:
+    return to_yaml_type(match.group(1))
 
   return typestr
 
 def doxygen2rst(text):
   text = re.sub(r'<tt>\s*(.*?)\s*<\/tt>', r'``\1``', text)
   text = re.sub(r'\\c ([^ ,;\.]+)', r'``\1``', text)
   text = re.sub(r'\\\w+ ', '', text)
   return text
for line in self.header:
           enum.values.append(EnumValue(val, comment, config))
     if state != State.Finished:
       raise Exception('Not finished by the end of file')
 
     for option in options:
       if option.type not in ['bool', 'unsigned', 'int', 'std::string',
                              'std::vector<std::string>',
                              'std::vector<IncludeCategory>',
-                             'std::vector<RawStringFormat>']:
+                             'std::vector<RawStringFormat>',
+                             'std::optional<unsigned>']:
         if option.type in enums:
           option.enum = enums[option.type]
         elif option.type in nested_structs:
           option.nested_struct = nested_structs[option.type]
         else:
           raise Exception('Unknown type: %s' % option.type)
     return options
 

clang/include/clang/Format/Format.h

enum BitFieldColonSpacingStyle : int8_t {
     ///   unsigned bf: 2;
     /// \endcode
     BFCS_After
   };
   /// The BitFieldColonSpacingStyle to use for bitfields.
   /// \version 12
   BitFieldColonSpacingStyle BitFieldColonSpacing;
 
+  /// The number of columns to use to indent the contents of braced init lists.
+  /// If unset, ``ContinuationIndentWidth`` is used.
+  /// \code
+  ///   AlignAfterOpenBracket: AlwaysBreak
+  ///   BracedInitializerIndentWidth: 2
+  ///
+  ///   void f() {
+  ///     SomeClass c{
+  ///       "foo",
+  ///       "bar",
+  ///       "baz",
+  ///     };
+  ///     auto s = SomeStruct{
+  ///       .foo = "foo",
+  ///       .bar = "bar",
+  ///       .baz = "baz",
+  ///     };
+  ///     SomeArrayT a[3] = {
+  ///       {
+  ///         foo,
+  ///         bar,
+  ///       },
+  ///       {
+  ///         foo,
+  ///         bar,
+  ///       },
+  ///       SomeArrayT{},
+  ///     };
+  ///   }
+  /// \endcode
+  /// \version 17
+  std::optional<unsigned> BracedInitializerIndentWidth;
+
   /// Different ways to wrap braces after control statements.
   enum BraceWrappingAfterControlStatementStyle : int8_t {
     /// Never wrap braces after a control statement.
     /// \code
     ///   if (foo()) {
     ///   } else {
     ///   }
     ///   for (int i = 0; i < 10; ++i) {

   /// Pointer and reference alignment styles are going to be updated according
   /// to the preferences found in the file.
   /// ``PointerAlignment`` is then used only as fallback.
   /// \version 3.7
   bool DerivePointerAlignment;
 
   /// Disables formatting completely.
   /// \version 3.7
   bool DisableFormat;
 
   /// Different styles for empty line after access modifiers.
   /// ``EmptyLineBeforeAccessModifier`` configuration handles the number of
   /// empty lines between two access modifiers.
   enum EmptyLineAfterAccessModifierStyle : int8_t {
     /// Remove all empty lines after access modifiers.
     /// \code
     ///   struct foo {
     ///   private:
     ///     int i;
     ///   protected:
     ///     int j;
     ///     /* comment */
     ///   public:
     ///     foo() {}
     ///   private:
     ///   protected:
     ///   };
     /// \endcode
     ELAAMS_Never,
return AccessModifierOffset == R.AccessModifierOffset &&
            AlwaysBreakBeforeMultilineStrings ==
                R.AlwaysBreakBeforeMultilineStrings &&
            AlwaysBreakTemplateDeclarations ==
                R.AlwaysBreakTemplateDeclarations &&
            AttributeMacros == R.AttributeMacros &&
            BinPackArguments == R.BinPackArguments &&
            BinPackParameters == R.BinPackParameters &&
            BitFieldColonSpacing == R.BitFieldColonSpacing &&
+           BracedInitializerIndentWidth == R.BracedInitializerIndentWidth &&
            BreakAfterAttributes == R.BreakAfterAttributes &&
            BreakAfterJavaFieldAnnotations == R.BreakAfterJavaFieldAnnotations &&
            BreakArrays == R.BreakArrays &&
            BreakBeforeBinaryOperators == R.BreakBeforeBinaryOperators &&
            BreakBeforeBraces == R.BreakBeforeBraces &&
            BreakBeforeConceptDeclarations == R.BreakBeforeConceptDeclarations &&
            BreakBeforeInlineASMColon == R.BreakBeforeInlineASMColon &&
            BreakBeforeTernaryOperators == R.BreakBeforeTernaryOperators &&
            BreakConstructorInitializers == R.BreakConstructorInitializers &&
            BreakInheritanceList == R.BreakInheritanceList &&
            BreakStringLiterals == R.BreakStringLiterals &&
            ColumnLimit == R.ColumnLimit && CommentPragmas == R.CommentPragmas &&
            CompactNamespaces == R.CompactNamespaces &&
            ConstructorInitializerIndentWidth ==
                R.ConstructorInitializerIndentWidth &&
            ContinuationIndentWidth == R.ContinuationIndentWidth &&
            Cpp11BracedListStyle == R.Cpp11BracedListStyle &&
            DerivePointerAlignment == R.DerivePointerAlignment &&
            DisableFormat == R.DisableFormat &&
            EmptyLineAfterAccessModifier == R.EmptyLineAfterAccessModifier &&
            EmptyLineBeforeAccessModifier == R.EmptyLineBeforeAccessModifier &&
            ExperimentalAutoDetectBinPacking ==
                R.ExperimentalAutoDetectBinPacking &&
            FixNamespaceComments == R.FixNamespaceComments &&
            ForEachMacros == R.ForEachMacros &&
            IncludeStyle.IncludeBlocks == R.IncludeStyle.IncludeBlocks &&
            IncludeStyle.IncludeCategories == R.IncludeStyle.IncludeCategories &&

clang/lib/Format/ContinuationIndenter.cpp

void ContinuationIndenter::moveStatePastScopeOpener(LineState &State,
   unsigned NewIndent;
   unsigned LastSpace = CurrentState.LastSpace;
   bool AvoidBinPacking;
   bool BreakBeforeParameter = false;
   unsigned NestedBlockIndent = std::max(CurrentState.StartOfFunctionCall,
                                         CurrentState.NestedBlockIndent);
   if (Current.isOneOf(tok::l_brace, TT_ArrayInitializerLSquare) ||
       opensProtoMessageField(Current, Style)) {
     if (Current.opensBlockOrBlockTypeList(Style)) {
       NewIndent = Style.IndentWidth +
                   std::min(State.Column, CurrentState.NestedBlockIndent);
+    } else if (Current.is(tok::l_brace)) {
+      NewIndent =
+          CurrentState.LastSpace + Style.BracedInitializerIndentWidth.value_or(
+                                       Style.ContinuationIndentWidth);
     } else {
       NewIndent = CurrentState.LastSpace + Style.ContinuationIndentWidth;
     }
-    const FormatToken *NextNoComment = Current.getNextNonComment();
+    const FormatToken *NextNonComment = Current.getNextNonComment();
     bool EndsInComma = Current.MatchingParen &&
                        Current.MatchingParen->Previous &&
                        Current.MatchingParen->Previous->is(tok::comma);
     AvoidBinPacking = EndsInComma || Current.is(TT_DictLiteral) ||
                       Style.Language == FormatStyle::LK_Proto ||
                       Style.Language == FormatStyle::LK_TextProto ||
                       !Style.BinPackArguments ||
-                      (NextNoComment &&
-                       NextNoComment->isOneOf(TT_DesignatedInitializerPeriod,
-                                              TT_DesignatedInitializerLSquare));
+                      (NextNonComment && NextNonComment->isOneOf(
+                                             TT_DesignatedInitializerPeriod,
     BreakBeforeParameter = EndsInComma;
     if (Current.ParameterCount > 1)
       NestedBlockIndent = std::max(NestedBlockIndent, State.Column + 1);
   } else {
     NewIndent =
         Style.ContinuationIndentWidth +
         std::max(CurrentState.LastSpace, CurrentState.StartOfFunctionCall);
 

clang/lib/Format/Format.cpp

static void mapping(IO &IO, FormatStyle &Style) {
     IO.mapOptional("AlwaysBreakBeforeMultilineStrings",
                    Style.AlwaysBreakBeforeMultilineStrings);
     IO.mapOptional("AlwaysBreakTemplateDeclarations",
                    Style.AlwaysBreakTemplateDeclarations);
     IO.mapOptional("AttributeMacros", Style.AttributeMacros);
     IO.mapOptional("BinPackArguments", Style.BinPackArguments);
     IO.mapOptional("BinPackParameters", Style.BinPackParameters);
     IO.mapOptional("BitFieldColonSpacing", Style.BitFieldColonSpacing);
+    IO.mapOptional("BracedInitializerIndentWidth",
+                   Style.BracedInitializerIndentWidth);
     IO.mapOptional("BraceWrapping", Style.BraceWrapping);
     IO.mapOptional("BreakAfterAttributes", Style.BreakAfterAttributes);
     IO.mapOptional("BreakAfterJavaFieldAnnotations",
                    Style.BreakAfterJavaFieldAnnotations);
     IO.mapOptional("BreakArrays", Style.BreakArrays);
     IO.mapOptional("BreakBeforeBinaryOperators",
                    Style.BreakBeforeBinaryOperators);
     IO.mapOptional("BreakBeforeConceptDeclarations",
static void mapping(IO &IO, FormatStyle &Style) {
     IO.mapOptional("ColumnLimit", Style.ColumnLimit);
     IO.mapOptional("CommentPragmas", Style.CommentPragmas);
     IO.mapOptional("CompactNamespaces", Style.CompactNamespaces);
     IO.mapOptional("ConstructorInitializerIndentWidth",
                    Style.ConstructorInitializerIndentWidth);
     IO.mapOptional("ContinuationIndentWidth", Style.ContinuationIndentWidth);
     IO.mapOptional("Cpp11BracedListStyle", Style.Cpp11BracedListStyle);
     IO.mapOptional("DerivePointerAlignment", Style.DerivePointerAlignment);
     IO.mapOptional("DisableFormat", Style.DisableFormat);
     IO.mapOptional("EmptyLineAfterAccessModifier",
                    Style.EmptyLineAfterAccessModifier);
     IO.mapOptional("EmptyLineBeforeAccessModifier",
                    Style.EmptyLineBeforeAccessModifier);
     IO.mapOptional("ExperimentalAutoDetectBinPacking",
                    Style.ExperimentalAutoDetectBinPacking);
     IO.mapOptional("FixNamespaceComments", Style.FixNamespaceComments);
     IO.mapOptional("ForEachMacros", Style.ForEachMacros);
FormatStyle getLLVMStyle(FormatStyle::LanguageKind Language) {
   LLVMStyle.AlwaysBreakAfterReturnType = FormatStyle::RTBS_None;
   LLVMStyle.AlwaysBreakAfterDefinitionReturnType = FormatStyle::DRTBS_None;
   LLVMStyle.AlwaysBreakBeforeMultilineStrings = false;
   LLVMStyle.AlwaysBreakTemplateDeclarations = FormatStyle::BTDS_MultiLine;
   LLVMStyle.AttributeMacros.push_back("__capability");
   LLVMStyle.BitFieldColonSpacing = FormatStyle::BFCS_Both;
   LLVMStyle.BinPackArguments = true;
   LLVMStyle.BinPackParameters = true;
+  LLVMStyle.BracedInitializerIndentWidth = std::nullopt;
   LLVMStyle.BraceWrapping = {/*AfterCaseLabel=*/false,
                              /*AfterClass=*/false,
                              /*AfterControlStatement=*/FormatStyle::BWACS_Never,
                              /*AfterEnum=*/false,
                              /*AfterFunction=*/false,
                              /*AfterNamespace=*/false,
                              /*AfterObjCDeclaration=*/false,
                              /*AfterStruct=*/false,
FormatStyle getLLVMStyle(FormatStyle::LanguageKind Language) {
   LLVMStyle.BreakStringLiterals = true;
   LLVMStyle.ColumnLimit = 80;
   LLVMStyle.CommentPragmas = "^ IWYU pragma:";
   LLVMStyle.CompactNamespaces = false;
   LLVMStyle.ConstructorInitializerIndentWidth = 4;
   LLVMStyle.ContinuationIndentWidth = 4;
   LLVMStyle.Cpp11BracedListStyle = true;
   LLVMStyle.DerivePointerAlignment = false;
   LLVMStyle.DisableFormat = false;
   LLVMStyle.EmptyLineAfterAccessModifier = FormatStyle::ELAAMS_Never;
   LLVMStyle.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_LogicalBlock;
   LLVMStyle.ExperimentalAutoDetectBinPacking = false;
   LLVMStyle.FixNamespaceComments = true;
   LLVMStyle.ForEachMacros.push_back("foreach");
   LLVMStyle.ForEachMacros.push_back("Q_FOREACH");
   LLVMStyle.ForEachMacros.push_back("BOOST_FOREACH");
   LLVMStyle.IfMacros.push_back("KJ_IF_MAYBE");

clang/unittests/Format/ConfigParseTest.cpp

CHECK_PARSE("PenaltyBreakOpenParenthesis: 1234", PenaltyBreakOpenParenthesis,
               1234u);
   CHECK_PARSE("PenaltyExcessCharacter: 1234", PenaltyExcessCharacter, 1234u);
   CHECK_PARSE("PenaltyReturnTypeOnItsOwnLine: 1234",
               PenaltyReturnTypeOnItsOwnLine, 1234u);
   CHECK_PARSE("SpacesBeforeTrailingComments: 1234",
               SpacesBeforeTrailingComments, 1234u);
   CHECK_PARSE("IndentWidth: 32", IndentWidth, 32u);
   CHECK_PARSE("ContinuationIndentWidth: 11", ContinuationIndentWidth, 11u);
+  CHECK_PARSE("BracedInitializerIndentWidth: 34", BracedInitializerIndentWidth,
+              34);
   CHECK_PARSE("CommentPragmas: '// abc$'", CommentPragmas, "// abc$");
 
   Style.QualifierAlignment = FormatStyle::QAS_Right;
   CHECK_PARSE("QualifierAlignment: Leave", QualifierAlignment,
               FormatStyle::QAS_Leave);
   CHECK_PARSE("QualifierAlignment: Right", QualifierAlignment,
               FormatStyle::QAS_Right);
   CHECK_PARSE("QualifierAlignment: Left", QualifierAlignment,
               FormatStyle::QAS_Left);
   CHECK_PARSE("QualifierAlignment: Custom", QualifierAlignment,

clang/unittests/Format/FormatTest.cpp

TEST_F(FormatTest, DesignatedInitializers) {
   verifyFormat("const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa = {\n"
                "    [1] = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,\n"
                "    [2] = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,\n"
                "    [3] = cccccccccccccccccccccccccccccccccccccc,\n"
                "    [4] = dddddddddddddddddddddddddddddddddddddd,\n"
                "    [5] = eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee};");
 }
 
+TEST_F(FormatTest, BracedInitializerIndentWidth) {
+  auto Style = getLLVMStyleWithColumns(60);
+  Style.BinPackArguments = true;
+  Style.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
+  Style.BracedInitializerIndentWidth = 6;
+
+  // Non-initializing braces are unaffected by BracedInitializerIndentWidth.
+  verifyFormat("enum class {\n"
+               "  One,\n"
+               "  Two,\n"
+               "};\n",
+               Style);
+  verifyFormat("class Foo {\n"
+               "  Foo() {}\n"
+               "  void bar();\n"
+               "};\n",
+               Style);
+  verifyFormat("void foo() {\n"
+               "  auto bar = baz;\n"
+               "  return baz;\n"
+               "};\n",
+               Style);
+  verifyFormat("auto foo = [&] {\n"
+               "  auto bar = baz;\n"
+               "  return baz;\n"
+               "};\n",
+               Style);
+  verifyFormat("{\n"
+               "  auto bar = baz;\n"
+               "  return baz;\n"
+               "};\n",
+               Style);
+  // Non-brace initialization is unaffected by BracedInitializerIndentWidth.
+  verifyFormat("SomeClass clazz(\n"
+               "    \"xxxxxxxxxxxxxxxxxx\", \"yyyyyyyyyyyyyyyyyy\",\n"
+               "    \"zzzzzzzzzzzzzzzzzz\");\n",
+               Style);
+
+  // The following types of initialization are all affected by
+  // BracedInitializerIndentWidth. Aggregate initialization.
+  verifyFormat("int LooooooooooooooooooooooooongVariable[2] = {\n"
+               "      10000000, 20000000};",
+               Style);
+  verifyFormat("SomeStruct s{\n"
+               "      \"xxxxxxxxxxxxxxxx\", \"yyyyyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzzzzz\"};\n",
+               Style);
+  // Designated initializers.
+  verifyFormat("int LooooooooooooooooooooooooongVariable[1] = {\n"
+               "      [0] = 10000000, [1] = 20000000};",
+               Style);
+  verifyFormat("SomeStruct s{\n"
+               "      .foo = \"xxxxxxxxxxxxx\",\n"
+               "      .bar = \"yyyyyyyyyyyyy\",\n"
+               "      .baz = \"zzzzzzzzzzzzz\"};\n",
+               Style);
+  // List initialization.
+  verifyFormat("SomeStruct s{\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "};\n",
+               Style);
+  verifyFormat("SomeStruct{\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "};\n",
+               Style);
+  verifyFormat("new SomeStruct{\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "};\n",
+               Style);
+  // Member initializer.
+  verifyFormat("class SomeClass {\n"
+               "  SomeStruct s{\n"
+               "        \"xxxxxxxxxxxxx\",\n"
+               "        \"yyyyyyyyyyyyy\",\n"
+               "        \"zzzzzzzzzzzzz\",\n"
+               "  };\n"
+               "};\n",
+               Style);
+  // Constructor member initializer.
+  verifyFormat("SomeClass::SomeClass : strct{\n"
+               "                             \"xxxxxxxxxxxxx\",\n"
+               "                             \"yyyyyyyyyyyyy\",\n"
+               "                             \"zzzzzzzzzzzzz\",\n"
+               "                       } {}\n",
+               Style);
+  // Copy initialization.
+  verifyFormat("SomeStruct s = SomeStruct{\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "};\n",
+               Style);
+  // Copy list initialization.
+  verifyFormat("SomeStruct s = {\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "};\n",
+               Style);
+  // Assignment operand initialization.
+  verifyFormat("s = {\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "};\n",
+               Style);
+  // Returned object initialization.
+  verifyFormat("return {\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "};\n",
+               Style);
+  // Initializer list.
+  verifyFormat("auto initializerList = {\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "};\n",
+               Style);
+  // Function parameter initialization.
+  verifyFormat("func({\n"
+               "      \"xxxxxxxxxxxxx\",\n"
+               "      \"yyyyyyyyyyyyy\",\n"
+               "      \"zzzzzzzzzzzzz\",\n"
+               "});\n",
+               Style);
+  // Nested init lists.
+  verifyFormat("SomeStruct s = {\n"
+               "      {{init1, init2, init3, init4, init5},\n"
+               "       {init1, init2, init3, init4, init5}}};\n",
+               Style);
+  verifyFormat("SomeStruct s = {\n"
+               "      {{\n"
+               "             .init1 = 1,\n"
+               "             .init2 = 2,\n"
+               "             .init3 = 3,\n"
+               "             .init4 = 4,\n"
+               "             .init5 = 5,\n"
+               "       },\n"
+               "       {init1, init2, init3, init4, init5}}};\n",
+               Style);
+  verifyFormat("SomeArrayT a[3] = {\n"
+               "      {\n"
+               "            foo,\n"
+               "            bar,\n"
+               "      },\n"
+               "      {\n"
+               "            foo,\n"
+               "            bar,\n"
+               "      },\n"
+               "      SomeArrayT{},\n"
+               "}\n",
+               Style);
+  verifyFormat("SomeArrayT a[3] = {\n"
+               "      {foo},\n"
+               "      {\n"
+               "            {\n"
+               "                  init1,\n"
+               "                  init2,\n"
+               "                  init3,\n"
+               "            },\n"
+               "            {\n"
+               "                  init1,\n"
+               "                  init2,\n"
+               "                  init3,\n"
+               "            },\n"
+               "      },\n"
+               "      {baz},\n"
+               "}\n",
+               Style);
+
+  // Aligning after open braces unaffected by BracedInitializerIndentWidth.
+  Style.AlignAfterOpenBracket = FormatStyle::BAS_Align;
+  verifyFormat("SomeStruct s{\"xxxxxxxxxxxxx\", \"yyyyyyyyyyyyy\",\n"
+               "             \"zzzzzzzzzzzzz\"};\n",
+               Style);
+}
+
 TEST_F(FormatTest, NestedStaticInitializers) {
   verifyFormat("static A x = {{{}}};\n");
   verifyFormat("static A x = {{{init1, init2, init3, init4},\n"
                "               {init1, init2, init3, init4}}};",
                getLLVMStyleWithColumns(50));
 
   verifyFormat("somes Status::global_reps[3] = {\n"
                "    {kGlobalRef, OK_CODE, NULL, NULL, NULL},\n"