This effectively reverts a4d4859dc70c046ad928805ddeaf8fa101793394 which
didn't fix the problem that `int*,` was not counted as "Left" alignment.
Fixes#150327
The [Google C++ Style
Guide](https://google.github.io/styleguide/cppguide.html#Pointer_and_Reference_Expressions)
is being changed to specify that spaces should go after the
asterisk/ampersand, rather than permitting either before or after on a
file-by-file basis.
The new requirement is:
> When referring to a pointer or reference (variable declarations or
> definitions, arguments, return types, template parameters, etc.),
> you must not place a space before the asterisk/ampersand. Use a
> space to separate the type from the declared name (if present).
The [Google ObjC
style](https://google.github.io/styleguide/objcguide.html) is silent on
this matter, but the de-facto style is not being modified at this time.
So, keep DerivePointerAlignment enabled for ObjC language mode.
Sorting by stem gives nicer results when various header file names are
substrings of other header file names. For example, a CLI application
with a main header named analyze.h and an analyze-xxx.h header for each
subcommand currently will always put analyze.h last after all the
analyze-xxx.h headers, but putting analyze.h first instead is arguably
nicer to read.
TLDR; Instead of
```
#include "analyze-blame.h"
#include "analyze.h"
```
You'd get
```
#include "analyze.h"
#include "analyze-blame.h"
```
Let's allow sorting by stem instead of full path by adding
IgnoreExtension to SortIncludes.
This PR addresses instances of compiler warning C4146 that can be
replaced with std::numeric_limits. Specifically, these are cases where a
literal such as '-1ULL' was used to assign a value to a uint64_t
variable. The intent is much cleaner if we use the appropriate
std::numeric_limits value<Type>::max() for these cases.
Addresses #147439
This allows simplification of code that checks if a token is an
Objective-C keyword.
Also, delete the following in
UnwrappedLineParser::parseStructuralElement():
- an else-after-break in the tok::at case
- the copypasted code in the tok::objc_autoreleasepool case
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>
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.
* 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`.
- Add a `CHECK_PARSE` for `AcrossComments`.
- Add a `CHECK_PARSE_NESTED_BOOL` for `AlignFunctionPointers`.
- Remove redundant statements.
- Clean up documentation.
