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>
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.
This piece of code made the program crash.
```Verilog
function pkg::t get
(int t = 2,
int f = 2);
```
The way the code is supposed to be parsed is that UnwrappedLineParser
should identify the function header, and then TokenAnnotator should
recognize the result. But the code in UnwrappedLineParser would
mistakenly not recognize it due to the `::`. Then TokenAnnotator would
recognize the comma both as TT_VerilogInstancePortComma and
TT_VerilogTypeComma. The code for annotating the instance port comma
used `setFinalizedType`. The program would crash when it tried to set
it to another type.
The code in UnwrappedLineParser now recognizes the `::` token.
The are other cases in which TokenAnnotator would recognize the comma as
both of those types, for example if the `function` keyword is removed.
The type is now set using `setType` instead so that the program does not
crash. The developer no longer knows why he used `setFinalizedType`
back then.
The part of the code for parsing Verilog module instantiations
dereferenced a pointer without checking for null pointer. The pointer
may be null if the input is not complete and a line starts with a comma.
A macro definition needs its own scope stack in the annotator, so we add
the MacroBodyScopes stack and use ScopeStack to refer to it when in the
macro definition body.
Also, we need to have a scope type for a child block because its parent
line is parsed (and thus the scope type for the braces is popped off the
scope stack) before the lines in the child block are.
Fixes#99271.
It doesn't make sense to remove the space between new/delete and a
C-style cast when SpaceBeforeParensOptions.AfterPlacementOperator is set
to false.
Fixes#105628.
Address #101550 by adding OwnLineWithBrace option for RequiresClausePosition. This permits placing a following '{' on the same line as the requires clause.
Thus, instead of:
```
bool Foo ()
requires(true)
{
return true;
}
```
we have:
```
bool Foo ()
requires(true) {
return true;
}
```
If the function body is empty, we'll get:
```
bool Foo ()
requires(true) {}
```
I attempted to get a line break between the open and close braces, but
failed. Perhaps that's fine -- it's rare and only happens in the empty
body case.
By default, clang-format packs binary operations, but it may be
desirable to have compound operations be on individual lines instead of
being packed.
This PR adds the option `BreakBinaryOperations` to break up large
compound binary operations to be on one line each.
This applies to all logical and arithmetic/bitwise binary operations
Maybe partially addresses #79487 ?
Closes#58014Closes#57280
