Fixes https://github.com/llvm/llvm-project/issues/173583
clang-format mis-formats C compound literals used in macro bodies, e.g.
`#define getAddr(v, type) &(type){v}`, treating `{...}` as a
block/function body
and reflowing the macro with backslashes and spaces.
This change:
- Recognizes `&( ... ){ ... }` patterns in macro bodies and marks the
brace as a braced-init.
- Improves parsing stability for braced lists in macro bodies.
Tests:
- FormatTests
---------
Co-authored-by: owenca <owenpiano@gmail.com>
The directives should not change the indentation level. Previously the
program erroneously added an indentation level when it saw the
`function` keyword.
The brace wrapping for Java records should now behave similar to
classes. Before, opening braces for Java records were always placed in
the same line as the record definition.
`UnwrappedLineParser::parseBracedList` had no
explicit handling for the `requires` keyword, so it would just call
`nextToken()` instead of properly parsing the `requires` expression.
This fix adds a case for `tok::kw_requires` in `parseBracedList`,
calling `parseRequiresExpression` to handle it correctly, matching the
existing behavior in `parseParens`.
Fixes https://github.com/llvm/llvm-project/issues/162984.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
Formatting this piece of code made the program crash.
```
class TypedVecListRegOperand<RegisterClass Reg, int lanes, string eltsize>
: RegisterOperand<Reg, "printTypedVectorList<" # lanes # ", '"
# eltsize # "'>">;
```
The line starting with the `#` was treated as a separate preprocessor
directive line. Then the code dereferenced a null pointer when it tried
to continue parsing the first line that did not end in a semicolon.
Now the 2 problems are fixed.
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
`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.
