It appears that this regressed the formatting of initializer lists in some
cases, see comments on https://reviews.llvm.org/D114583. I'll follow-up
by adding regression tests for these.
This reverts commit c41b3b0fa0.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D116000
https://github.com/llvm/llvm-project/issues/49804
Interaction between IndentExternBlock and AfterExternBlock means you cannot have AfterExternBlock = true and IndentExternBlock = NoIndent/Indent
This patch resolves that
```
BraceWrapping:
AfterExternBlock: true
IndentExternBlock: AfterExternBlock
```
Fixes: #49804
Reviewed By: HazardyKnusperkeks, curdeius, owenpan
Differential Revision: https://reviews.llvm.org/D115879
The alignment fix introduced by https://reviews.llvm.org/D104388 caused a regression whereby formatting of code that follows the lambda block is incorrect i.e. separate expressions are put on the same line.
Differential Revision: https://reviews.llvm.org/D115738
Relevant issue: https://github.com/llvm/llvm-project/issues/52705
When the `DisableFormat` option of `clang-format` is set to `true` and a JSON file is formatted, the ephemeral variable binding that is added to the top-level object is not removed from the formatted file. For example, this JSON:
```
{
"key": "value"
}
```
Is reformatted to:
```
x = {
"key": "value"
}
```
Which is not valid JSON syntax. This fix avoids the addition of this binding when `DisableFormat` is set to `true`, ensuring that it cannot be left behind when formatting is disabled.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D115769Fixes#52705
https://github.com/llvm/llvm-project/issues/52715Fixes#52715
`AllowShortBlocksOnASingleLine` seems to never be checked for "Empty" as such if its used it will be considered "Always" as we only ever check `AllowShortBlocksOnASingleLine != Never`
This impacts C++ as well as C# hence the slightly duplicated test.
Reviewed By: curdeius, jbcoe
Differential Revision: https://reviews.llvm.org/D115794
https://github.com/llvm/llvm-project/issues/48642
clang-format does not respect raw string literals when sorting includes
```
const char *RawStr = R"(
)";
```
Running clang-format over with SortIncludes enabled transforms this code to:
```
const char *RawStr = R"(
)";
```
The following code tries to minimize this impact during IncludeSorting, by treating R"( and )" as equivalent of // clang-format off/on
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D115168Fixes#48642
Responding to a Discord call to help {D113977} and heavily inspired by the unlanded {D34225} add some support to help coroutinues from not being formatted from
```for co_await(auto elt : seq)```
to
```
for
co_await(auto elt : seq)
```
Because of the dominance of clang-format in the C++ community, I don't think we should make it the blocker that prevents users from embracing the newer parts of the standard because we butcher the layout of some of the new constucts.
Reviewed By: HazardyKnusperkeks, Quuxplusone, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D114859
Make sure we do not try to change line comments that are non-regular, i.e. do
not start with "//" or "#". This can for example happen when "//" is
broken into two lines with an escaped newline.
Previously, clang-format would not correctly identify preprocessor
directives directly following a conflict marker, which would result in
violating the formatter's invariants.
The provided test fails in assert mode before this change.
{D110833} regressed behavior of spaces before parentheses for operators, this revision reverts that so that operators are handled as they were before.
I think in hindsight it was a mistake to try and consume operator behaviour in with the function behaviour, I think Operators can be considered a special style. Its seems the code is getting confused as to if this is a function declaration or definition.
I think latterly we can consider adding an operator parentheses specific custom option but this should have been explicitly called out as it can impact projects.
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D114696
https://bugs.llvm.org/show_bug.cgi?id=52517
clang-format is butchering modules, this could easily become a barrier to entry for modules given clang-formats wide spread use.
Prevent the following from adding spaces around the `:` (cf was considering the ':' as an InheritanceColon)
Reviewed By: HazardyKnusperkeks, owenpan, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D114151
https://bugs.llvm.org/show_bug.cgi?id=52595
missing space between `T(&&)` but not between `T (&` due to && being incorrectly thought of as `UnaryOperator` rather than `PointerOrReference`
```
int operator()(T (&)[N]) { return 0; }
int operator()(T(&&)[N]) { return 1; }
```
Existing Unit tests are changed because actually I think they are originally incorrect, and are inconsistent with the (&) cases that are 4 or 5 lines above them.
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D114519
https://bugs.llvm.org/show_bug.cgi?id=47936
Using the MultiLine setting for BraceWrapping.AfterControlStatement appears to disable AllowShortFunctionsOnASingleLine, even in cases without any control statements
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D114521
Looks like the work of {D113393} requires manual clang-formatting intervention.
Removal of the space between `auto` and `{}`
Reviewed By: HazardyKnusperkeks, Quuxplusone
Differential Revision: https://reviews.llvm.org/D113826
The coding style of some projects requires to have more control on space
before opening parentheses.
The goal is to add the support of clang-format to more projects.
For example adding a space only for function definitions or
declarations.
This revision adds SpaceBeforeParensOptions to configure each option
independently from one another.
Differentiel Revision: https://reviews.llvm.org/D110833
Currently constructor initializer lists sometimes format incorrectly
when there is a preprocessor directive in the middle of the list.
This patch fixes the issue when parsing the initilizer list by
ignoring the preprocessor directive when checking if a block is
part of an initializer list.
rdar://82554274
Reviewed By: MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D109951
Earlier during the development of {D69764} I felt it was no longer necessary to
ensure we were not trying to change code which didn't need to change
and we felt this could be removed, however I'd like to bring this back for now
as I am seeing some false positives in terms of the "replacements"
What I see is the generation of a replacement which is a "No Op" on the original
code, I think this comes about because of the merging of replacements:
```
static const a;
->
const static a;
->
static const a;
```
The replacements don't really merge, in such a way as to identify when we have gone
back to the original
Also remove the Penalty as I'm not using it (and it became marked as set and no used,
I'd rather get rid of it if it means nothing)
I think we need to do this step for now, as many people use the --output-replacements-xml
to identify that the file "needs a clang-format"
The same can be seen with the -n or --dry-run option as this uses the replacements
to drive the error/warning output.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D110392
Commit a44ab17025 added a unit test that fails to build with
-Werror which causes build bot breaks on bots that include that
option in their build. This patch just adds the necessary casts to
silence the warnings.
Developers these days seem to argue over east vs west const like they used to argue over tabs vs whitespace or the various bracing style. These previous arguments were mainly eliminated with tools like `clang-format` that allowed those rules to become part of your style guide. Anyone who has been using clang-format in a large team over the last couple of years knows that we don't have those religious arguments any more, and code reviews are more productive.
https://www.youtube.com/watch?v=fv--IKZFVO8https://mariusbancila.ro/blog/2018/11/23/join-the-east-const-revolution/https://www.youtube.com/watch?v=z6s6bacI424
The purpose of this revision is to try to do the same for the East/West const discussion. Move the debate into the style guide and leave it there!
In addition to the new `ConstStyle: Right` or `ConstStyle: Left` there is an additional command-line argument `--const-style=left/right` which would allow an individual developer to switch the source back and forth to their own style for editing, and back to the committed style before commit. (you could imagine an IDE might offer such a switch)
The revision works by implementing a separate pass of the Annotated lines much like the SortIncludes and then create replacements for constant type declarations.
Differential Revision: https://reviews.llvm.org/D69764
Commits 58494c856a, f6bc614546, and 0fc27ef196 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
Add backward compatibility tests for mapping the deprecated
ConstructorInitializerAllOnOneLineOrOnePerLine and
AllowAllConstructorInitializersOnNextLine to
PackConstructorInitializers.
Differential Revision: https://reviews.llvm.org/D108882
LLVM 13.0.0-rc2 shows change of behaviour in enum and interface BraceWrapping (likely before we simply didn't wrap) but may be related to {D99840}
Logged as https://bugs.llvm.org/show_bug.cgi?id=51640
This change ensure AfterEnum works for
`internal|public|protected|private enum A {` in the same way as it works for `enum A {` in C++
A similar issue was also observed with `interface` in C#
Reviewed By: krasimir, owenpan
Differential Revision: https://reviews.llvm.org/D108810
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
TypeScript 4.3 added a new "override" keyword for class members. This
lets clang-format know about it, so it can format code using it
properly.
Reviewed By: krasimir
Differential Revision: https://reviews.llvm.org/D108692
This fixes up a regression we found from
https://reviews.llvm.org/D107267: in specific contexts, clang-format
stopped breaking after the `)` in TypeScript decorations. There were no test cases covering this, so I added one.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D108538
Marek Kurdej