AllowShortNamespacesOnASingleLine assumes that there is no newline
before the namespace brace, however, there is no actual reason this
shouldn't be compatible with BraceWrapping.AfterNamespace = true.
This is a little tricky in the implementation because
UnwrappedLineFormatter works on lines, so being flexible about the
offsets is awkward.
Not sure if there is a better pattern for combining the 'AllowShort'
options with the various configurations of BraceWrapping, but this
seemed mostly reasonable. Really, it would almost be preferable to just
pattern match on the direct token stream, rather than the
AnnotatedLines, but I'm not seeing a straightforward way to do that.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
The use of Cpp11BracedListStyle with BinPackArguments=False avoids bin
packing until reaching a hard-coded limit of 20 items. This is an
arbitrary choice. Introduce a new style option to allow disabling this
limit.
In clang-format, multiline templates have the `>` on the same line as
the last parameter:
```c++
template <
typename Foo,
typename Bar>
void foo() {
```
I would like to add an option to put the `>` on the next line, like
this:
```c++
template <
typename Foo,
typename Bar
>
void foo() {
```
An example of a large project that uses this style is NVIDIA's CUTLASS,
here is an example:
https://github.com/NVIDIA/cutlass/blob/main/include/cutlass/epilogue/dispatch_policy.hpp#L149-L156
My reasoning is that it reminds me of this style of braces:
```c++
if (foo()) {
bar();
baz();}
```
Most people agree this is better:
```c++
if (foo()) {
bar();
baz();
}
```
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Near the ColumnLimit a break could be inserted before a right parens
with BlockIndent without a break after the matching left parens. Avoid
these hanging right parens by disallowing breaks before right parens
unless there was a break after the left parens.
Fixes#103306
The penalty for breaking before a member access is hard-coded to 150.
Add a configuration option to allow setting it.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
`export { ... }` blocks can get a bit long, so I thought it would make
sense to have an option that makes it so their contents are not indented
(basically the same argument as for namespaces).
This is based on the `NamespaceIndentation` option, except that there is
no option to control the behaviour of `export` blocks when nested because
nesting them doesn’t really make sense.
Additionally, brace wrapping of short `export { ... }` blocks is now controlled by the
`AllowShortBlocksOnASingleLine` option. There is no separate option just for `export`
blocks because you can just write e.g. `export int x;` instead of `export { int x; }`.
This closes#121723.
It wraps the body of namespace with additional newlines, turning this code:
```
namespace N {
int function();
}
```
into the following:
```
namespace N {
int function();
}
```
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
This fixes#101363 which is a resurrection of a previously opened but
never completed review: https://reviews.llvm.org/D11851
The feature is to allow code like the following not to be broken across
multiple lines:
```
namespace foo { class bar; }
namespace foo { namespace bar { class baz; } }
```
Code like this is commonly used for forward declarations, which are
ideally kept compact. This is also apparently the format that
include-what-you-use will insert for forward declarations.
Also, fix an off-by-one error in `CompactNamespaces` code. For nested
namespaces with 3 or more namespaces, it was incorrectly compacting
lines which were 1 or two spaces over the `ColumnLimit`, leading to
incorrect formatting results.
Move the checks related to breaking before right braces and right parens
earlier to avoid conflicting checks that prevent breaking based on the
left-hand token. This allows properly formatting declarations with
pointers and references at a minimum.
* Convert `ReflowComments` from boolean into a new `enum` which can take
on the value `RCS_Never`, `RCS_IndentOnly`, or `RCS_Always`. The first
one is equivalent to the old `false`, the third one is `true`, and the
middle one means that multiline comments should only have their
indentation corrected, which is what Doxygen users will want.
* Preserve backward compatibility while parsing `ReflowComments`.
Enabling AlignConsecutiveDeclarations also aligns function prototypes
or declarations. This is often unexpected as typically function
prototypes, especially in public headers, don't use any padding.
Setting AlignFunctionDeclarations to false will skip this alignment.
It is by default set to true to keep compatibility with prior
versions to not make unexpected changes.
Fixes#74320
