[clang-format] Restrict the special handling for K&R C to C/C++

Commits 58494c856a15, f6bc614546e1, and 0fc27ef19670 added special
handlings for K&R C function definitions and caused some
JavaScript

[clang-format] Restrict the special handling for K&R C to C/C++

Commits 58494c856a15, f6bc614546e1, and 0fc27ef19670 added special
handlings for K&R C function definitions and caused some
JavaScript/TypeScript regressions which were addressed in D107267,
D108538, and D108620. This patch would have prevented these known
regressions and will fix any unknown ones.

Differential Revision: https://reviews.llvm.org/D109582

show more ...

[clang-format] Add PackConstructorInitializers backward compat test

Add backward compatibility tests for mapping the deprecated
ConstructorInitializerAllOnOneLineOrOnePerLine and
AllowAllConstructor

[clang-format] Add PackConstructorInitializers backward compat test

Add backward compatibility tests for mapping the deprecated
ConstructorInitializerAllOnOneLineOrOnePerLine and
AllowAllConstructorInitializersOnNextLine to
PackConstructorInitializers.

Differential Revision: https://reviews.llvm.org/D108882

show more ...

[clang-format] Group options that pack constructor initializers

Add a new option PackConstructorInitializers and deprecate the
related options ConstructorInitializerAllOnOneLineOrOnePerLine and
Allo

[clang-format] Group options that pack constructor initializers

Add a new option PackConstructorInitializers and deprecate the
related options ConstructorInitializerAllOnOneLineOrOnePerLine and
AllowAllConstructorInitializersOnNextLine. Below is the mapping:

PackConstructorInitializers ConstructorInitializer... AllowAll...
Never - -
BinPack false -
CurrentLine true false
NextLine true true

The option value Never fixes PR50549 by always placing each
constructor initializer on its own line.

Differential Revision: https://reviews.llvm.org/D108752

show more ...

[clang-format] Distinguish K&R C function definition and attribute

This is a follow-up to https://reviews.llvm.org/D107950 which
missed user-defined types in K&R C.

Differential Revision: https://r

[clang-format] Distinguish K&R C function definition and attribute

This is a follow-up to https://reviews.llvm.org/D107950 which
missed user-defined types in K&R C.

Differential Revision: https://reviews.llvm.org/D107961

show more ...

Revert "[clang-format] Distinguish K&R C function definition and attribute"

This reverts commit de763c4037157e60551ba227ccd0ed02e109c317.

Causing test failures on the Arm/AArch64 quick bots:
https:

Revert "[clang-format] Distinguish K&R C function definition and attribute"

This reverts commit de763c4037157e60551ba227ccd0ed02e109c317.

Causing test failures on the Arm/AArch64 quick bots:
https://lab.llvm.org/buildbot/#/builders/188/builds/2202

show more ...

[clang-format] Distinguish K&R C function definition and attribute

This is a follow-up to https://reviews.llvm.org/D107950 which
missed user-defined types in K&R C.

Differential Revision: https://r

[clang-format] Distinguish K&R C function definition and attribute

This is a follow-up to https://reviews.llvm.org/D107950 which
missed user-defined types in K&R C.

Differential Revision: https://reviews.llvm.org/D107961

show more ...

[clang-format] improve distinction of K&R function definitions vs attributes

After
https://github.com/llvm/llvm-project/commit/9da70ab3d43c79116f80fc06aa7cf517374ce42c
we saw a few regressions aroun

[clang-format] improve distinction of K&R function definitions vs attributes

After
https://github.com/llvm/llvm-project/commit/9da70ab3d43c79116f80fc06aa7cf517374ce42c
we saw a few regressions around trailing attribute definitions and in
typedefs (examples in the added test cases). There's some tension
distinguishing K&R definitions from attributes at the parser level,
where we have to decide if we need to put the type of the K&R definition
on a new unwrapped line before we have access to the rest of the line,
so we're scanning backwards and looking for a pattern like f(a, b). But
this type of pattern could also be an attribute macro, or the whole
declaration could be a typedef itself. I updated the code to check for a
typedef at the beginning of the line and to not consider raw identifiers
as possible first K&R declaration (but treated as an attribute macro
instead). This is not 100% correct heuristic, but I think it should be
reasonably good in practice, where we'll:
* likely be in some very C-ish code when using K&R style (e.g., stuff
that uses `struct name a;` instead of `name a;`
* likely be in some very C++-ish code when using attributes
* unlikely mix up the two in the same declaration.

Ideally, we should only decide to add the unwrapped line before the K&R
declaration after we've scanned the rest of the line an noticed the
variable declarations and the semicolon, but the way the parser is
organized I don't see a good way to do this in the current parser, which
only has good context for the previously visited tokens. I also tried
not emitting an unwrapped line there and trying to resolve the situation
later in the token annotator and the continuation indenter, and that
approach seems promising, but I couldn't make it to work without
messing up a bunch of other cases in unit tests.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D107950

show more ...

[clang-format] handle trailing comments in function definition detection

A follow-up to
https://github.com/llvm/llvm-project/commit/f6bc614546e169bb1b17a29c422ebace038e6c62
where we handle the case

[clang-format] handle trailing comments in function definition detection

A follow-up to
https://github.com/llvm/llvm-project/commit/f6bc614546e169bb1b17a29c422ebace038e6c62
where we handle the case where the semicolon is followed by a trailing
comment.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D107907

show more ...

[clan-format] detect function definitions more conservatively

https://reviews.llvm.org/D105964 updated the detection of function
definitions. It had the unfortunate effect to start marking object
de

[clan-format] detect function definitions more conservatively

https://reviews.llvm.org/D105964 updated the detection of function
definitions. It had the unfortunate effect to start marking object
definitions with attribute-like macros as function definitions.

This addresses this issue.

Reviewed By: owenpan

Differential Revision: https://reviews.llvm.org/D107269

show more ...

[clang-format] Fix aligning with linebreaks #2

This amends c5243c63cda3c740d6e9c7e501f6518c21688da3 to fix formatting
continued function calls with BinPacking = false.

Differential Revision: https:

[clang-format] Fix aligning with linebreaks #2

This amends c5243c63cda3c740d6e9c7e501f6518c21688da3 to fix formatting
continued function calls with BinPacking = false.

Differential Revision: https://reviews.llvm.org/D106773

show more ...

[clang-format] Correctly attach enum braces with ShortEnums disabled

Previously, with AllowShortEnumsOnASingleLine disabled, enums that would have otherwise fit on a single line would always put the

[clang-format] Correctly attach enum braces with ShortEnums disabled

Previously, with AllowShortEnumsOnASingleLine disabled, enums that would have otherwise fit on a single line would always put the opening brace on its own line.
This patch ensures that these enums will only put the brace on its own line if the existing attachment rules indicate that it should.

Reviewed By: HazardyKnusperkeks, curdeius

Differential Revision: https://reviews.llvm.org/D99840

show more ...

[clang-format] Break an unwrapped line at a K&R C parameter decl

Break an unwrapped line before the first parameter declaration in a
K&R C function definition.

This fixes PR51074.

Differential Rev

[clang-format] Break an unwrapped line at a K&R C parameter decl

Break an unwrapped line before the first parameter declaration in a
K&R C function definition.

This fixes PR51074.

Differential Revision: https://reviews.llvm.org/D106112

show more ...

[clang-format] Make BreakAfterReturnType work with K&R C functions

This fixes PR50999.

Differential Revision: https://reviews.llvm.org/D105964

[clang-format] Fix the issue that empty lines being removed at the beginning of namespace

This is a bug fix of https://bugs.llvm.org/show_bug.cgi?id=50116

Reviewed By: MyDeveloperDay

Differential

[clang-format] Fix the issue that empty lines being removed at the beginning of namespace

This is a bug fix of https://bugs.llvm.org/show_bug.cgi?id=50116

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D104044

show more ...

[clang-format] [PR50702] Lamdba processing does not respect AfterClass and AfterNamespace

https://bugs.llvm.org/show_bug.cgi?id=50702

I believe {D44609} may be too aggressive with brace wrapping ru

[clang-format] [PR50702] Lamdba processing does not respect AfterClass and AfterNamespace

https://bugs.llvm.org/show_bug.cgi?id=50702

I believe {D44609} may be too aggressive with brace wrapping rules which doesn't always apply to Lamdbas

The introduction of BeforeLambdaBody and AllowShortLambdasOnASingleLine has impact on brace handling on other block types, which I suspect we didn't see before as people may not be using the BeforeLambdaBody style

From what I can tell this can be seen by the unit test I change as its not honouring the orginal LLVM brace wrapping style for the `Fct()` function

I added a unit test from PR50702 and have removed some of the code (which has zero impact on the unit test, which kind of suggests its unnecessary), some additional attempt has been made to try and ensure we'll only break on what is actually a LamdbaLBrace

Reviewed By: HazardyKnusperkeks

Differential Revision: https://reviews.llvm.org/D104222

show more ...

[clang-format] PR50525 doesn't handle AlignConsecutiveAssignments correctly in some situations

https://bugs.llvm.org/show_bug.cgi?id=50525

AlignConsecutiveAssignments/Declarations cause incorrect a

[clang-format] PR50525 doesn't handle AlignConsecutiveAssignments correctly in some situations

https://bugs.llvm.org/show_bug.cgi?id=50525

AlignConsecutiveAssignments/Declarations cause incorrect alignment in the presence of a DesignatedInitializerPeriod (https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html)

```
static NTSTATUS stg(PLW_STREAM Stream, int identity)
{
NTSTATUS status;
BYTE payload[256] = {'l', 'h', 'o', 't', 's', 'e'};
struct dm_rpc_header header = {.drh_magic = DRH_MAGIC,
.drh_op_code = RPC_OP_ECHO,
.drh_payload_size = sizeof(payload),
.drh_body_size = sizeof(payload),
.drh_request_id = 1};
header.drh_version = identity;
```

This fix addresses that by ensuring the period isn't ignored

Reviewed By: HazardyKnusperkeks

Differential Revision: https://reviews.llvm.org/D104900

show more ...

[Clang-Format] Add ReferenceAlignment directive

This introduces ReferenceAlignment style option modeled around
PointerAlignment.
Style implementors can specify Left, Right, Middle or Pointer to
foll

[Clang-Format] Add ReferenceAlignment directive

This introduces ReferenceAlignment style option modeled around
PointerAlignment.
Style implementors can specify Left, Right, Middle or Pointer to
follow whatever the PointerAlignment option specifies.

Differential Revision: https://reviews.llvm.org/D104096

show more ...

[clang-format] Add IfMacros option

https://bugs.llvm.org/show_bug.cgi?id=49354

Differential Revision: https://reviews.llvm.org/D102730

[clang-format] Fix a bug that indents else-comment-if incorrectly

PR50809

Differential Revision: https://reviews.llvm.org/D104774

[clang-format] Add new LambdaBodyIndentation option

Currently the lambda body indents relative to where the lambda signature is located. This instead lets the user
choose to align the lambda body re

[clang-format] Add new LambdaBodyIndentation option

Currently the lambda body indents relative to where the lambda signature is located. This instead lets the user
choose to align the lambda body relative to the parent scope that contains the lambda declaration. Thus:

someFunction([] {
lambdaBody();
});

will always have the same indentation of the body even when the lambda signature goes on a new line:

someFunction(
[] {
lambdaBody();
});

whereas before lambdaBody would be indented 6 spaces.

Differential Revision: https://reviews.llvm.org/D102706

show more ...

[Format] Fix incorrect pointer/reference detection

https://llvm.org/PR50568

When an overloaded operator is called, its argument must be an
expression.

Before:
void f() { a.operator()(a *a); }

[Format] Fix incorrect pointer/reference detection

https://llvm.org/PR50568

When an overloaded operator is called, its argument must be an
expression.

Before:
void f() { a.operator()(a *a); }

After:
void f() { a.operator()(a * a); }

Reviewed By: HazardyKnusperkeks, curdeius, MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D103678

show more ...

[clang-format] distinguish function type casts after 21c18d5a04316891110cecc2bf37ce51533decba

https://github.com/llvm/llvm-project/commit/21c18d5a04316891110cecc2bf37ce51533decba
improved the detect

[clang-format] distinguish function type casts after 21c18d5a04316891110cecc2bf37ce51533decba

https://github.com/llvm/llvm-project/commit/21c18d5a04316891110cecc2bf37ce51533decba
improved the detection of multiplication in function call argument lists,
but unintentionally regressed the handling of function type casts (there
were no tests covering those).
This patch improves the detection of function type casts and adds a few tests.

Reviewed By: HazardyKnusperkeks

Differential Revision: https://reviews.llvm.org/D104209

show more ...

[clang-format] Adds a formatter for aligning arrays of structs

This adds a new formatter to arrange array of struct initializers into
neat columns.

Differential Revision: https://reviews.llvm.org/D

[clang-format] Adds a formatter for aligning arrays of structs

This adds a new formatter to arrange array of struct initializers into
neat columns.

Differential Revision: https://reviews.llvm.org/D101868

show more ...

[Format] Fix incorrect pointer detection

https://llvm.org/PR50429

Before:
void f() { f(float(1), a *a); }

After:
void f() { f(float(1), a * a); }

Signed-off-by: Yilong Guo <yilong.guo@int

[Format] Fix incorrect pointer detection

https://llvm.org/PR50429

Before:
void f() { f(float(1), a *a); }

After:
void f() { f(float(1), a * a); }

Signed-off-by: Yilong Guo <yilong.guo@intel.com>

Reviewed By: HazardyKnusperkeks, curdeius

Differential Revision: https://reviews.llvm.org/D103589

show more ...

[clang-format] Add PPIndentWidth option

This allows to set a different indent width for preprocessor statements.

Example:

#ifdef __linux_
# define FOO
#endif

int main(void)
{
return 0;
}

[clang-format] Add PPIndentWidth option

This allows to set a different indent width for preprocessor statements.

Example:

#ifdef __linux_
# define FOO
#endif

int main(void)
{
return 0;
}

Differential Revision: https://reviews.llvm.org/D103286

show more ...