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
Make all code go through FormatTokenSource instead of going around it, which
makes changes to TokenSource brittle.
Add LLVM_DEBUG in FormatTokenSource to be able to follow the token stream.
When building clang-format with -Wall on Visual Studio 20119 we see the following, prevent this the only -Wall error
```
..FormatTokenLexer.cpp(45) : warning C4868: compiler may not enforce left-to-right evaluation order in braced initializer list
```
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D113844
1. IndexTokenSource::getNextToken cannot return nullptr; some code was
still written assuming it can; make getNextToken more resilient against
incorrect input and fix its call-sites.
2. Change various asserts that can happen due to user provided input to
conditionals in the code.
Makes clang-format bail out if an in-memory source file with an
unsupported BOM is handed in instead of creating source locations that
are violating clang's assumptions.
In the future, we should add support to better transport error messages
like this through clang-format instead of printing to stderr and not
creating any changes.
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
[NFC] This patch fixes URLs containing "master". Old URLs were either broken or
redirecting to the new URL.
Reviewed By: #libc, ldionne, mehdi_amini
Differential Revision: https://reviews.llvm.org/D113186
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
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
Currently, we have no front-end type for ppc_fp128 type in IR. PowerPC
target generates ppc_fp128 type from long double now, but there's option
(-mabi=(ieee|ibm)longdouble) to control it and we're going to do
transition from IBM extended double-double ppc_fp128 to IEEE fp128 in
the future.
This patch adds type __ibm128 which always represents ppc_fp128 in IR,
as what GCC did for that type. Without this type in Clang, compilation
will fail if compiling against future version of libstdcxx (which uses
__ibm128 in headers).
Although all operations in backend for __ibm128 is done by software,
only PowerPC enables support for it.
There's something not implemented in this commit, which can be done in
future ones:
- Literal suffix for __ibm128 type. w/W is suitable as GCC documented.
- __attribute__((mode(IF))) should be for __ibm128.
- Complex __ibm128 type.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D93377
Add backward compatibility tests for mapping the deprecated
ConstructorInitializerAllOnOneLineOrOnePerLine and
AllowAllConstructorInitializersOnNextLine to
PackConstructorInitializers.
Differential Revision: https://reviews.llvm.org/D108882
The default value of the now deprecated
AllowAllConstructorInitializersOnNextLine was always true
regardless of the value of BasedOnStyle. This patch fixes the typo
in the code that handles the related backward compatibility.
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
Clean up the detection of parameter declarations in K&R C function
definitions. Also make it more precise by requiring the second
token after the r_paren to be either a star or keyword/identifier.
Differential Revision: https://reviews.llvm.org/D108094
After
9da70ab3d4
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
A follow-up to
f6bc614546
where we handle the case where the semicolon is followed by a trailing
comment.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D107907
Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception licence.
Differential Revision: https://reviews.llvm.org/D107528
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
The patch https://reviews.llvm.org/D105964 (58494c856a)
updated detection of function declaration names. It had the unfortunate
consequence that it started breaking between `function` and the function
name in some cases in JavaScript code.
This patch addresses this.
Reviewed By: MyDeveloperDay, owenpan
Differential Revision: https://reviews.llvm.org/D107267
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
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
https://bugs.llvm.org/show_bug.cgi?id=50727
When processing C# Lambda expression in the indentation can goes a little wrong,
resulting the the closing } being at the wrong indentation level and meaning the remaining part of the file is
incorrectly indented.
This can be a fairly common pattern for when C# wants to peform a UI action from a thread,
and it wants to invoke that action on the main thread
Reviewed By: exv, jbcoe
Differential Revision: https://reviews.llvm.org/D104388
I find as I develop I'm moving between many different languages C++,C#,JavaScript all the time. As I move between the file types I like to keep `clang-format` as my formatting tool of choice. (hence why I initially added C# support in {D58404}) I know those other languages have their own tools but I have to learn them all, and I have to work out how to configure them, and they may or may not have integration into my IDE or my source code integration.
I am increasingly finding that I'm editing additional JSON files as part of my daily work and my editor and git commit hooks are just not setup to go and run [[ https://stedolan.github.io/jq/ | jq ]], So I tend to go to [[ https://jsonformatter.curiousconcept.com/ | JSON Formatter ]] and copy and paste back and forth. To get nicely formatted JSON. This is a painful process and I'd like a new one that causes me much less friction.
This has come up from time to time:
{D10543}
https://stackoverflow.com/questions/35856565/clang-format-a-json-filehttps://bugs.llvm.org/show_bug.cgi?id=18699
I would like to stop having to do that and have formatting JSON as a first class clang-format support `Language` (even if it has minimal style settings at present).
This revision adds support for formatting JSON using the inbuilt JSON serialization library of LLVM, With limited control at present only over the indentation level
This adds an additional Language into the .clang-format file to separate the settings from your other supported languages.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D93528
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
This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.
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
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
21c18d5a04
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
The previous implementation would accidentally still sort the individual
named imports, even if the module reference was in a clang-format off
block.
Differential Revision: https://reviews.llvm.org/D104101
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
This re-applies the old patch D27651, which was never landed, into the
latest "main" branch, without understanding the code. I just applied
the changes "mechanically" and made it compiling again.
This makes the right pointer alignment working as expected.
Fixes https://llvm.org/PR27353
For instance
const char* const* v1;
float const* v2;
SomeVeryLongType const& v3;
was formatted as
const char *const * v1;
float const * v2;
SomeVeryLongType const &v3;
This patch keep the *s or &s aligned to the right, next to their variable.
The above example is now formatted as
const char *const *v1;
float const *v2;
SomeVeryLongType const &v3;
It is a pity that this still does not work with clang-format in 2021,
even though there was a fix available in 2016. IMHO right pointer alignment
is the default case in C, because syntactically the pointer belongs to the
variable.
See
int* a, b, c; // wrong, just the 1st variable is a pointer
vs.
int *a, *b, *c; // right
Prominent example is the Linux kernel coding style.
Some styles argue the left pointer alignment is better and declaration
lists as shown above should be avoided. That's ok, as different projects
can use different styles, but this important style should work too.
I hope that somebody that has a better understanding about the code,
can take over this patch and land it into main.
For now I must maintain this fork to make it working for our projects.
Cheers,
Gerhard.
Differential Revision: https://reviews.llvm.org/D103245
{D74265} reduced the aggressiveness of line breaking following C# attributes, however this change removed any support for attributes on properties, causing significant ugliness to be introduced.
This revision goes some way to addressing that by re-introducing the more aggressive check to `mustBreakBefore()`, but constraining it to the most common cases where we use properties which should not impact the "caller info attributes" or the "[In , Out]" decorations that are normally put on pinvoke
It does not address my additional concerns of the original change regarding multiple C# attributes, as these are somewhat incorrectly handled by virtue of the fact its not recognising the second attribute as an attribute at all. But instead thinking its an array.
The purpose of this revision is to get back to where we were for the most common of cases as a stepping stone to resolving this. However {D74265} has broken a lot of C# code and this revision will go someway alone to addressing the majority.
Reviewed By: jbcoe, HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D103307
This inheritance list style has been widely adopted by Symantec,
a division of Broadcom Inc. It breaks after the commas that
separate the base-specifiers:
class Derived : public Base1,
private Base2
{
};
Differential Revision: https://reviews.llvm.org/D103204
WG14 adopted N2645 and WG21 EWG has accepted P2334 in principle (still
subject to full EWG vote + CWG review + plenary vote), which add
support for #elifdef as shorthand for #elif defined and #elifndef as
shorthand for #elif !defined. This patch adds support for the new
preprocessor directives.
This fixes two errors:
Previously, clang-format was splitting up type identifiers from the
nullable ?. This changes this behavior so that the type name sticks with
the operator.
Additionally, nullable operators attached to return types in interface
functions were not parsed correctly. Digging deeper, it looks like
interface bodies were being parsed differently than classes and structs,
causing MustBeDeclaration to be incorrect for interface members. They
now share the same logic.
One other change is reintroducing the CSharpNullable type independent of
JsTypeOptionalQuestion. Despite having a similar semantic purpose, their
actual syntax differs quite a bit.
Reviewed By: MyDeveloperDay, curdeius
Differential Revision: https://reviews.llvm.org/D101860
Fixes https://llvm.org/PR35099.
I'm not sure if this decision was intentional but its definitely confusing for users.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D101628
This fixes another bogus build error on gcc, e.g. https://lab.llvm.org/buildbot/#/builders/118/builds/2504.
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux-perf/llvm/clang/lib/Format/UnwrappedLineFormatter.cpp:424:42: error: binding ‘clang::format::FormatToken* const’ to reference of type ‘clang::format::FormatToken*&’ discards qualifiers
auto IsElseLine = [&First = TheLine->First]() -> bool {
^
Previously, the JavaScript import sorter would ignore `// clang-format
off` and `on` comments. This change fixes that. It tracks whether
formatting is enabled for a stretch of imports, and then only sorts and
merges the imports where formatting is enabled, in individual chunks.
This means that there's no meaningful total order when module references are mixed
with blocks that have formatting disabled. The alternative approach
would have been to sort all imports that have formatting enabled in one
group. However that raises the question where to insert the
formatting-off block, which can also impact symbol visibility (in
particular for exports). In practice, sorting in chunks probably isn't a
big problem.
This change also simplifies the general algorithm: instead of tracking
indices separately and sorting them, it just sorts the vector of module
references. And instead of attempting to do fine grained tracking of
whether the code changed order, it just prints out the module references
text, and compares that to the previous text. Given that source files
typically have dozens, but not even hundreds of imports, the performance
impact seems negligible.
Differential Revision: https://reviews.llvm.org/D101515
This fixes another bogus build error on gcc, e.g. https://lab.llvm.org/buildbot/#/builders/110/builds/2974.
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/clang/lib/Format/TokenAnnotator.cpp:3412:34: error: binding ‘const clang::format::FormatStyle’ to reference of type ‘clang::format::FormatStyle&’ discards qualifiers
auto ShouldAddSpacesInAngles = [&Style = this->Style,
^
This fixes a bogus build error on gcc, e.g. https://lab.llvm.org/buildbot/#/builders/110/builds/2973.
/home/ssglocal/clang-cmake-x86_64-avx2-linux/clang-cmake-x86_64-avx2-linux/llvm/clang/lib/Format/TokenAnnotator.cpp:3097:53: error: binding ‘const clang::SourceRange’ to reference of type ‘clang::SourceRange&’ discards qualifiers
auto HasExistingWhitespace = [&Whitespace = Right.WhitespaceRange]() {
^
A need for such an option came up in a few libc++ reviews. That's because libc++ has both code in C++03 and newer standards.
Currently, it uses `Standard: C++03` setting for clang-format, but this breaks e.g. u8"string" literals.
Also, angle brackets are the only place where C++03-specific formatting needs to be applied.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D101344
Clang-format was indenting the lines following the `?` in the added test
case by +5 instead of +4. This only happens in a very specific
situation, where the `?` is followed by a multiline block comment, as in
the example. This fix addresses this without regressing any of the
existing tests.
Differential Revision: https://reviews.llvm.org/D101033
The if condition was testing the current element, but
forgot to check the previous element (doh), so it
would fail depending on sort order of the imports.
Differential Revision: https://reviews.llvm.org/D101020
`asserts` is a pseudo keyword in TypeScript used in return types.
Wrapping after it triggers automatic semicolon insertion, which
breaks the code semantics/syntax.
`asserts` is different from other pseudo keywords in that it is
specific to TS and only carries meaning in a very specific location.
Thus introducing a token type is probably overkill.
Differential Revision: https://reviews.llvm.org/D100953
Previously, clang-format would erroneously merge import and export
statements. These need to be kept separate, as the semantics differ.
Differential Revision: https://reviews.llvm.org/D100752
Fixes https://llvm.org/PR41870.
Checks for newlines in option Style.EmptyLineBeforeAccessModifier are now based on the formatted new lines and not on the new lines in the file.
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D99503
The current logic for access modifiers in classes ignores the option 'MaxEmptyLinesToKeep=1'. It is therefore impossible to have a coding style that requests one empty line after an access modifier. The patch allows the user to configure how many empty lines clang-format should add after an access modifier. This will remove lines if there are to many and will add them if there are missing.
Reviewed By: MyDeveloperDay, curdeius
Differential Revision: https://reviews.llvm.org/D98237
Multiple lines importing from the same URL can be merged:
import {X} from 'a';
import {Y} from 'a';
Merge to:
import {X, Y} from 'a';
This change implements this merge operation. It takes care not to merge in
various corner case situations (default imports, star imports).
Differential Revision: https://reviews.llvm.org/D100466
This patch fixes left pointer alignment after pointer qualifiers of
operators. Currently "operator void const*()" is formatted with a space between
const and pointer despite setting PointerAlignment to Left.
AFAICS this has been broken since clang-format 10.
Reviewed By: MyDeveloperDay, curdeius
Differential Revision: https://reviews.llvm.org/D99458
In JavaScript, `- -1;` is legal syntax, the language allows unary minus.
However the two tokens must not collapse together: `--1` is prefix
decrement, i.e. different syntax.
Before:
- -1; ==> --1;
After:
- -1; ==> - -1;
This change makes no attempt to format this "nicely", given by all
likelihood this represents a programming mistake by the user, or odd
generated code.
The check is not guarded by language: this appears to be a problem in
Java as well, and will also be beneficial when formatting syntactically
incorrect C++ (e.g. during editing).
Differential Revision: https://reviews.llvm.org/D99495
Breaking a string literal or a function calls arguments with
AlignConsecutiveDeclarations or AlignConsecutiveAssignments did misalign
the continued line. E.g.:
void foo() {
int myVar = 5;
double x = 3.14;
auto str = "Hello"
"World";
}
or
void foo() {
int myVar = 5;
double x = 3.14;
auto str = "Hello"
"World";
}
Differential Revision: https://reviews.llvm.org/D98214
Commit
f7f9f94b2e
changed the indent of ObjC method arguments from +4 to +2, if the method
occurs after a block statement. I believe this was unintentional and there
was insufficient ObjC test coverage to catch this.
Example: `clang-format -style=google test.mm`
before:
```
void aaaaaaaaaaaaaaaaaaaaa(int c) {
if (c) {
f();
}
[dddddddddddddddddddddddddddddddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeeee:^(fffffffffffffff gggggggg) {
f(SSSSS, c);
}];
}
```
after:
```
void aaaaaaaaaaaaaaaaaaaaa(int c) {
if (c) {
f();
}
[dddddddddddddddddddddddddddddddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeeee:^(fffffffffffffff gggggggg) {
f(SSSSS, c);
}];
}
```
Differential Revision: https://reviews.llvm.org/D99063
This updates the canonical text proto raw string delimiter to `pb` for Google style, moving codebases towards a simpler and more consistent style.
Also updates a behavior where the canonical delimiter was not applied for raw strings with empty delimiters detected via well-known enclosing functions that expect a text proto, effectively making the canonical delimiter more viral. This feature is not widely used so this should be safe and more in line with promoting the canonicity of the canonical delimiter.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D97688
This commit removes the old way of handling Whitesmiths mode in favor of just setting the
levels during parsing and letting the formatter handle it from there. It requires a bit of
special-casing during the parsing, but ends up a bit cleaner than before. It also removes
some of switch/case unit tests that don't really make much sense when dealing with
Whitesmiths.
Differential Revision: https://reviews.llvm.org/D94500
This amends 25f753c51e.
When applying the child configurations we don't need any diagnostic,
because it was issued when first parsing them. So just drop everything
on the second parse.
Differential Revision: https://reviews.llvm.org/D96760
clang-format documentation states that having enabled
FixNamespaceComments one may expect below code:
c++
namespace a {
foo();
}
to be turned into:
c++
namespace a {
foo();
} // namespace a
In reality, no "// namespace a" was added. The problem was too high
value of kShortNamespaceMaxLines, which is used while deciding whether
a namespace is long enough to be formatted.
As with 9163fe2, clang-format idempotence is preserved.
Differential Revision: https://reviews.llvm.org/D87587
... without an active column limit.
Before line comments were not touched at all with ColumnLimit == 0.
Differential Revision: https://reviews.llvm.org/D96896
This is a bug fix of https://bugs.llvm.org/show_bug.cgi?id=49175
The expected code format:
unsigned int* a;
int* b;
unsigned int Const* c;
The actual code after formatting (without this patch):
unsigned int* a;
int* b;
unsigned int Const* c;
Differential Revision: https://reviews.llvm.org/D97137
Adds support for coding styles that make a separate indentation level for access modifiers, such as Code::Blocks or QtCreator.
The new option, `IndentAccessModifiers`, if enabled, forces the content inside classes, structs and unions (“records”) to be indented twice while removing a level for access modifiers. The value of `AccessModifierOffset` is disregarded in this case, aiming towards an ease of use.
======
The PR (https://bugs.llvm.org/show_bug.cgi?id=19056) had an implementation attempt by @MyDeveloperDay already (https://reviews.llvm.org/D60225) but I've decided to start from scratch. They differ in functionality, chosen approaches, and even the option name. The code tries to re-use the existing functionality to achieve this behavior, limiting possibility of breaking something else.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D94661
This allows the define BasedOnStyle: InheritParentConfig and then
clang-format looks into the parent directories for their
.clang-format and takes that as a basis.
Differential Revision: https://reviews.llvm.org/D93844
Adds an option to [clang-format] which sorts headers in an alphabetical manner using case only for tie-breakers. The options is off by default in favor of the current ASCIIbetical sorting style.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D95017
Add new option called InsertEmptyLineBeforeAccessModifier. Empty line
before access modifier is inerted if this option is set to true (which
is the default value, because clang-format always inserts empty lines
before access modifiers), otherwise empty lines are removed.
Fixes issue #16518.
Differential Revision: https://reviews.llvm.org/D93846
When sorting the known prefixes after length the if in the loop will hit
at most once, so we can return from there.
Also replace the inner loop with an algorithm, that makes it more
readable.
Differential Revision: https://reviews.llvm.org/D95081
* Adds an option to [clang-format] which sorts
headers in an alphabetical manner using case
only for tie-breakers. The options is off by
default in favor of the current ASCIIbetical
sorting style.
Reviewed By: curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D95017
Currently, empty lines and comments break alignment of assignments on consecutive
lines. This makes the AlignConsecutiveAssignments option an enum that allows controlling
whether empty lines or empty lines and comments should be ignored when aligning
assignments.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, tinloaf
Differential Revision: https://reviews.llvm.org/D93986
Currently, empty lines and comments break alignment of assignments on consecutive
lines. This makes the AlignConsecutiveAssignments option an enum that allows controlling
whether empty lines or empty lines and comments should be ignored when aligning
assignments.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, tinloaf
Differential Revision: https://reviews.llvm.org/D93986
This allows to ignore for example Qts emit when
AlignConsecutiveDeclarations is set, otherwise it is parsed as a type
and it results in some misformating:
unsigned char MyChar = 'x';
emit signal(MyChar);
Differential Revision: https://reviews.llvm.org/D93776
https://bugs.llvm.org/show_bug.cgi?id=48594
Empty or small templates were not being treated the same way as small classes especially when SplitEmptyRecord was set to true
This revision aims to help this by identifying a case when we should try not to merge the lines together
Reviewed By: curdeius, JohelEGP
Differential Revision: https://reviews.llvm.org/D93839
Formatting is not active after "clang-format on" due to merging lines while formatting is off. Also, use trimmed line. Behaviour with LF is different than with CRLF.
Reviewed By: curdeius, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D94206
If file contain BOM then first instruction (include or clang-format off) is ignored
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D94201
https://bugs.llvm.org/show_bug.cgi?id=48569
This is a tentative fix which addresses a PR raise regarding Case indentation when working with Whitesmiths Indentation
I could not find online any reference sources as to what the case indentation for Whitesmith's should be (or be allowed to be)
But according to the documentation, we don't obey the rules for Whitesmith's
```
In particular, the documentation states that this option is to "indent case labels one level from the switch statement. When false, use the same indentation level as for the switch statement."
```
The behaviour we add here is actually as the TODO in the tests used to state in {D67627}, but when {D82016} was added and I brought these tests out from being TODO I realized I changed the indentation.
Reviewed By: curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D93806
https://bugs.llvm.org/show_bug.cgi?id=48539
Add support for Qt Translator Comments to reflow
When reflown and a part of the comments are added on a new line, it should repeat these extra characters as part of the comment token.
Reviewed By: curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D93490
https://bugs.llvm.org/show_bug.cgi?id=48535
using `SpaceAfterCStyleCast: true`
```
size_t idx = (size_t) a;
size_t idx = (size_t) (a - 1);
```
is formatted as:
```
size_t idx = (size_t) a;
size_t idx = (size_t)(a - 1);
```
This revision aims to improve that by improving the function which tries to identify a CastRParen
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D93626
This overload should be used for better diagnostics when parsing configurations.
Now a failure to parse will list the filename (or <command-line>) instead of just `YAML`.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D93633
Summary: The clang-format may go wrong when handle c++ coroutine keywords and pointer.
The default value for PointerAlignment is PAS_Right. So the following format is good:
```
co_return *a;
```
But within some code style, the value for PointerAlignment is PAS_Left, the behavior goes wrong:
```
co_return* a;
```
test-plan: check-clang
reviewers: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D91245
A quick search of github.com, shows one common scenario for excessive use of //clang-format off/on is the indentation of #pragma's, especially around the areas of loop optimization or OpenMP
This revision aims to help that by introducing an `IndentPragmas` style, the aim of which is to keep the pragma at the current level of scope
```
for (int i = 0; i < 5; i++) {
// clang-format off
#pragma HLS UNROLL
// clang-format on
for (int j = 0; j < 5; j++) {
// clang-format off
#pragma HLS UNROLL
// clang-format on
....
```
can become
```
for (int i = 0; i < 5; i++) {
#pragma HLS UNROLL
for (int j = 0; j < 5; j++) {
#pragma HLS UNROLL
....
```
This revision also support working alongside the `IndentPPDirective` of `BeforeHash` and `AfterHash` (see unit tests for examples)
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D92753
clang-format see the `disable:` in __pragma(warning(disable:)) as ObjectiveC method call
Remove any line starting with `#` or __pragma line from being part of the ObjectiveC guess
https://bugs.llvm.org/show_bug.cgi?id=42434
Reviewed By: curdeius, krasimir
Differential Revision: https://reviews.llvm.org/D92922
This is a starting point to improve the handling of concepts in clang-format. There is currently no real formatting of concepts and this can lead to some odd formatting, e.g.
Reviewed By: mitchell-stellar, miscco, curdeius
Differential Revision: https://reviews.llvm.org/D79773
In JavaScript breaking before a `@tag` in a comment puts it on a new line, and
machinery that parses these comments will fail to understand such comments.
This adapts clang-format to not break before `@`. Similar functionality exists
for not breaking before `{`.
Reviewed By: mprobst
Differential Revision: https://reviews.llvm.org/D91078
In C++ with -Werror=comment, multiline comments are not allowed.
clang-format could accidentally introduce multiline comments when reflowing.
This adapts clang-format to not introduce multiline comments by not allowing a
break after `\`. Note that this does not apply to comment lines that already are
multiline comments, such as comments in macros.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D90949
In JavaScript some @tags can be followed by `{`, and machinery that parses
these comments will fail to understand the comment if followed by a line break.
clang-format already handles this case by not breaking before `{` in comments.
However this was not working in cases when the column limit falls within `@tag`
or between `@tag` and `{`. This adapts clang-format for this case.
Reviewed By: mprobst
Differential Revision: https://reviews.llvm.org/D90908
TokenAnnotator::splitPenalty() was always returning 0 for opening parens if
AlignAfterOpenBracket was set to BAS_DontAlign, so the preferred point for
line breaking was always after the open paren (and was ignoring
PenaltyBreakBeforeFirstCallParameter). This change restricts the zero
penalty to the AllowAllArgumentsOnNextLine case. This results in improved
formatting for FreeBSD where we set AllowAllArgumentsOnNextLine: false
and a high value for PenaltyBreakBeforeFirstCallParameter to avoid breaking
after the open paren.
Before:
```
functionCall(
paramA, paramB, paramC);
void functionDecl(
int A, int B, int C)
```
After:
```
functionCall(paramA, paramB,
paramC);
void functionDecl(int A, int B,
int C)
```
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D90246
After D86959 the code `#define lambda [](const decltype(x) &ptr) {}`
was formatted as `#define lambda [](const decltype(x) & ptr) {}` due to
now parsing the '&' token as a BinaryOperator. The problem was caused by
the condition `Line.InPPDirective && (!Left->Previous || !Left->Previous->is(tok::identifier))) {`
being matched and therefore not performing the checks for "previous token
is one of decltype/_Atomic/etc.". This patch moves those checks after the
existing if/else chain to ensure the left-parent token classification is
always run after checking whether the contents of the parens is an
expression or not.
This change also introduces a new TokenAnnotatorTest that checks the
token kind and Role of Tokens after analyzing them. This is used to check
for TT_PointerOrReference, in addition to indirectly testing this based
on the resulting formatting.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D88956
In order to drop the final callers to `SourceManager::getBuffer`, change
`FrontendInputFile` to use `Optional<MemoryBufferRef>`. Also updated
the "unowned" version of `SourceManager::createFileID` to take a
`MemoryBufferRef` (it now calls `MemoryBuffer::getMemBuffer`, which
creates a `MemoryBuffer` that does not own the buffer data).
Differential Revision: https://reviews.llvm.org/D89427
This allows removing the clangAST dependency from libclangToolingCore and
therefore allows clang-format to be built without depending on clangAST.
Before 1166 files had to be compiled for clang-format, now only 796.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D89708
Update `Lexer` / `Lexer::Lexer` to use `MemoryBufferRef` instead of
`MemoryBuffer*`. Callers that were acquiring a `MemoryBuffer*` via
`SourceManager::getBuffer` were updated, such that if they checked
`Invalid` they use `getBufferOrNone` and otherwise `getBufferOrFake`.
Differential Revision: https://reviews.llvm.org/D89398
Update clang/lib/Format and clang/lib/Rewrite to use a `MemoryBufferRef`
from `getBufferOrFake` instead of `MemoryBuffer*` from `getBuffer`.
No functionality change here, since the call sites weren't checking if
the buffer was valid.
Differential Revision: https://reviews.llvm.org/D89406
Some projects (e.g. FreeBSD) align pointers to the right but expect a
space between the '*' and any pointer qualifiers such as const. To handle
these cases this patch adds a new config option SpaceAroundPointerQualifiers
that can be used to configure whether spaces need to be added before/after
pointer qualifiers.
PointerAlignment = Right
SpaceAroundPointerQualifiers = Default/After:
void *const *x = NULL;
SpaceAroundPointerQualifiers = Before/Both
void * const *x = NULL;
PointerAlignment = Left
SpaceAroundPointerQualifiers = Default/Before:
void* const* x = NULL;
SpaceAroundPointerQualifiers = After/Both
void* const * x = NULL;
PointerAlignment = Middle
SpaceAroundPointerQualifiers = Default/Before/After/Both:
void * const * x = NULL;
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D88227
ClangFormat does not correctly handle an Objective-C interface declaration
with both lightweight generics and a protocol conformance.
This simple example:
```
@interface Foo : Bar <Baz> <Blech>
@end
```
means `Foo` extends `Bar` (a lightweight generic class whose type
parameter is `Baz`) and also conforms to the protocol `Blech`.
ClangFormat should not apply any changes to the above example, but
instead it currently formats it quite poorly:
```
@interface Foo : Bar <Baz>
<Blech>
@end
```
The bug is that `UnwrappedLineParser` assumes an open-angle bracket
after a base class name is a protocol list, but it can also be a
lightweight generic specification.
This diff fixes the bug by factoring out the logic to parse
lightweight generics so it can apply both to the declared class
as well as the base class.
Test Plan: New tests added. Ran tests with:
% ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
Confirmed tests failed before diff and passed after diff.
Reviewed By: sammccall, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D89496
The argument passed to the preprocessor macros `NS_SWIFT_NAME(x)` and
`CF_SWIFT_NAME(x)` is stringified before passing to
`__attribute__((swift_name("x")))`.
ClangFormat didn't know about this stringification, so its custom parser
tried to parse the argument(s) passed to the macro as if they were
normal function arguments.
That means ClangFormat currently incorrectly inserts whitespace
between `NS_SWIFT_NAME` arguments with colons and dots, so:
```
extern UIWindow *MainWindow(void) NS_SWIFT_NAME(getter:MyHelper.mainWindow());
```
becomes:
```
extern UIWindow *MainWindow(void) NS_SWIFT_NAME(getter : MyHelper.mainWindow());
```
which clang treats as a parser error:
```
error: 'swift_name' attribute has invalid identifier for context name [-Werror,-Wswift-name-attribute]
```
Thankfully, D82620 recently added the ability to treat specific macros
as "whitespace sensitive", meaning their arguments are implicitly
treated as strings (so whitespace is not added anywhere inside).
This diff adds `NS_SWIFT_NAME` and `CF_SWIFT_NAME` to
`WhitespaceSensitiveMacros` so their arguments are implicitly treated
as whitespace-sensitive.
Test Plan:
New tests added. Ran tests with:
% ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D89425
This improves the debugging experience since LLDB will print the enumerator
name instead of a decimal number. This changes TokenType to have uint8_t
as the underlying type and moves it after the remaining bitfields to avoid
increasing the size of FormatToken.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D87006
Summary:
The MacroExpander allows to expand simple (non-resursive) macro
definitions from a macro identifier token and macro arguments. It
annotates the tokens with a newly introduced MacroContext that keeps
track of the role a token played in expanding the macro in order to
be able to reconstruct the macro expansion from an expanded (formatted)
token stream.
Made Token explicitly copy-able to enable copying tokens from the parsed
macro definition.
Reviewers: sammccall
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D83296
Currently newer clang-format options cannot be included in .clang-format files, if not all users can be forced to use an updated version.
This patch tries to solve this by adding an option to clang-format, enabling to ignore unknown (newer) options.
Differential Revision: https://reviews.llvm.org/D86137
Some Java style guides and IDEs group Java static imports after
non-static imports. This patch allows clang-format to control
the location of static imports.
Patch by: @bc-lee
Reviewed By: MyDeveloperDay, JakeMerdichAMD
Differential Revision: https://reviews.llvm.org/D87201
https://bugs.llvm.org/show_bug.cgi?id=47461
The following change {D80940} caused a regression in code which ifdef's around the try and catch block cause incorrect brace placement around the catch
```
try
{
}
catch (...) {
// This is not a small function
bar = 1;
}
}
```
The brace after the catch will be placed on a newline
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D87291
We dereference the Left pointer throughout the parseParens() function apart from this single case - just add an non-null assertion and drop the check.
Fixes clang static analayzer null dereference warning.
In some situation shifts can be treated as a template, and is thus formatted as one. So, by doing a couple extra checks to assure that the condition doesn't contain a template, and is in fact a bit shift should solve this problem.
This is a fix for [[ https://bugs.llvm.org/show_bug.cgi?id=46969 | bug 46969 ]]
Reviewed By: MyDeveloperDay
Patch By: Saldivarcher
Differential Revision: https://reviews.llvm.org/D86581
When using the always break after return type setting:
Before:
SomeType funcdecl(LIST(uint64_t));
After:
SomeType
funcdecl(LIST(uint64_t));"
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D87007
Before: _Atomic(uint64_t) * a;
After: _Atomic(uint64_t) *a;
This treats _Atomic the same as the the TypenameMacros and decltype. It
also allows some cleanup by removing checks whether the token before a
paren is kw_decltype and instead checking for TT_TypeDeclarationParen.
While touching this code also extend the decltype test cases to also check
for typeof() and _Atomic(T).
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D86959
This adds a `AttributeMacros` configuration option that causes certain
identifiers to be parsed like a __attribute__((foo)) annotation.
This is motivated by our CHERI C/C++ fork which adds a __capability
qualifier for pointer/reference. Without this change clang-format parses
many type declarations as multiplications/bitwise-and instead.
I initially considered adding "__capability" as a new clang-format keyword,
but having a list of macros that should be treated as attributes is more
flexible since it can be used e.g. for static analyzer annotations or other language
extensions.
Example: std::vector<foo * __capability> -> std::vector<foo *__capability>
Depends on D86775 (to apply cleanly)
Reviewed By: MyDeveloperDay, jrtc27
Differential Revision: https://reviews.llvm.org/D86782
When guessing whether a closing paren is then end of a cast expression also
skip over pointer qualifiers while looking for TT_PointerOrReference.
This prevents some address-of and dereference operators from being parsed
as a binary operator.
Before:
x = (foo *const) * v;
x = (foo *const volatile restrict __attribute__((foo)) _Nonnull _Null_unspecified _Nonnull) & v;
After:
x = (foo *const)*v;
x = (foo *const volatile restrict __attribute__((foo)) _Nonnull _Null_unspecified _Nonnull)&v;
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D86716
Use spaces to align binary and ternary expressions when using AlignOperands and UT_AlignWithSpaces.
This fixes an oversight in the new UT_AlignWithSpaces option (see D75034), which did not correctly identify the alignment of binary/ternary expressions.
Reviewed By: curdeius
Patch by: fickert
Differential Revision: https://reviews.llvm.org/D85600
Summary:
The MultiLine option in BreakBeforeBraces was only handling standard
control statement, leading to invalid indentation with for each macros:
Previous behavior:
/* invalid: brace should be on the same line */
Q_FOREACH(int a; list)
{
foo();
}
/* valid */
Q_FOREACH(int longVariable;
list)
{
foo();
}
To fix this, simply add the TT_ForEachMacro kind in the list of
recognized control statements for the multiline option.
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=44632
Reviewers: MyDeveloperDay, mitchell-stellar
Reviewed by: mitchell-stellar
Contributed by: vthib
Subscribers: cfe-commits
Tags: #clang, #clang-format, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D85304
The underlying ABI forces FormatToken to have a lot of padding.
Currently (on x86-64 linux) `sizeof(FormatToken) == 288`. After this patch
`sizeof(FormatToken) == 232`.
No functional changes.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D84306
Summary:
https://bugs.llvm.org/show_bug.cgi?id=46383
When the c preprocessor stringizes tokens, the generated string literals
are affected by the whitespace. This means clang-format can affect
codegen silently, adding spaces and newlines to strings. Practically
speaking, the vast majority of cases will be harmless, only affecting
single identifiers or debug macros.
In the interest of doing no harm in other cases though, this introduces
a blacklist option 'WhitespaceSensitiveMacros', which contains a list of
names of function-like macros whose contents should not be touched by
clang-format, period. Clang-format can't automatically detect these
without a real compile context, so users will have to specify it
explicitly (it still beats clang-format off'ing at every invocation).
Defaults include "STRINGIZE", "PP_STRINGIZE", and "BOOST_PP_STRINGIZE".
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82620
Summary:
After D50078, we're experiencing unexpected un-indent using a style combining `AlignOperands: DontAlign` with `BreakBeforeTernaryOperators: false`, such as Google's JavaScript style:
```
% bin/clang-format -style=google ~/test.js
aaaaaaaaaaa = bbbbbbbb ? cccccccccccccccccc() :
dddddddddd ? eeeeeeeeeeeeee :
fffff;
```
The issue lies with the interaction of `AlignOperands: DontAlign` and the edited code section in ContinuationIndenter.cpp, which de-dents the intent by `Style.ContinuationIndentWidth`. From [[ ac3e5c4d93/clang/include/clang/Format/Format.h (L170) | the documentation ]] of AlignOperands: DontAlign:
> The wrapped lines are indented `ContinuationIndentWidth` spaces from the start of the line.
So the de-dent effectively erases the necessary `ContinuationIndentWidth` in that case.
This patch restores the `AlignOperands: DontAlign` behavior, producing:
```
% bin/clang-format -style=google ~/test.js
aaaaaaaaaaa = bbbbbbbb ? cccccccccccccccccc() :
dddddddddd ? eeeeeeeeeeeeee :
fffff;
```
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82199
Summary:
This patch fixes bug #44192
When clang-format is run with option AllowShortBlocksOnASingleLine, it is expected to either succeed in putting the short block with its control statement on a single line or fail and leave the block as is. When brace wrapping after control statement is activated, if the block + the control statement length is superior to column limit but the block alone is not, clang-format puts the block in two lines: one for the control statement and one for the block. This patch removes this unexpected behaviour. Current unittests are updated to check for this behaviour.
Patch By: Bouska
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D71512
Summary:
There should be no line break before the opening brace for Microsoft style property accessors when the accessor is a simple `{ get; set }`.
https://docs.microsoft.com/en-us/dotnet/csharp/properties
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D81467
Summary: This will put a space in `lock (process)` when spaces are required after keywords.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D81255
Summary:
This patch upstreams support for a new storage only bfloat16 C type.
This type is used to implement primitive support for bfloat16 data, in
line with the Bfloat16 extension of the Armv8.6-a architecture, as
detailed here:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
The bfloat type, and its properties are specified in the Arm Architecture
Reference Manual:
https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
In detail this patch:
- introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type.
This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.
The following people contributed to this patch:
- Luke Cheeseman
- Momchil Velikov
- Alexandros Lamprineas
- Luke Geeson
- Simon Tatham
- Ties Stuij
Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli
Reviewed By: SjoerdMeijer
Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76077
Summary:
https://bugs.llvm.org/show_bug.cgi?id=46130 from Twitter https://twitter.com/ikautak/status/1265998988232159232
I have seen this myself many times.. if you have format on save and you work in an editor where you are constantly saving (:w muscle memory)
If you are in the middle of editing and somehow you've missed a { or } in your code, somewhere, often way below where you are at the bottom of your file the namespace comment fixer will have put the namespace on the previous closing brace.
This leads to you having to fix up the bottom of the file.
This revision prevents that happening by performing an initial pass of the tokens and simply counting the number of `{` and `}` and ensuring they balance.
If they don't balance we don't do any namespace fixing as it will likely be unstable and incorrect.
Reviewed By: curdeius
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80830
Summary:
{D80144} introduce an ObjC regression
Only parse the `[]` if what follows is really an attribute
Reviewers: krasimir, JakeMerdichAMD
Reviewed By: krasimir
Subscribers: rdwampler, aaron.ballman, curdeius, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80547
Summary:
Its currently not possible to recreate the GNU style using the `BreakBeforeBraces: Custom` style due to a lack of missing `BeforeWhile` in the `BraceWrappingFlags`
The following request was raised to add `BeforeWhile` in a `do..while` context like `BeforeElse` and `BeforeCatch` to give greater control over the positioning of the `while`
https://bugs.llvm.org/show_bug.cgi?id=42164
Reviewers: krasimir, mitchell-stellar, sammccall
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79325
Summary:
https://bugs.llvm.org/show_bug.cgi?id=33890
This revision allow the microsoft `for each(.... in ...` nonstandard C++ extension which can be used in C++/CLI to be handled as a ForEach macro.
This prevents the breaking between the for and each onto a new line
Reviewed By: JakeMerdichAMD
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80228
Summary:
The following revision follows D80115 since @MyDeveloperDay and I apparently both had the same idea at the same time, for https://bugs.llvm.org/show_bug.cgi?id=45816 and my efforts on tooling support for AMDVLK, respectively.
This option aligns adjacent bitfield separators across lines, in a manner similar to AlignConsecutiveAssignments and friends.
Example:
```
struct RawFloat {
uint32_t sign : 1;
uint32_t exponent : 8;
uint32_t mantissa : 23;
};
```
would become
```
struct RawFloat {
uint32_t sign : 1;
uint32_t exponent : 8;
uint32_t mantissa : 23;
};
```
This also handles c++2a style bitfield-initializers with AlignConsecutiveAssignments.
```
struct RawFloat {
uint32_t sign : 1 = 0;
uint32_t exponent : 8 = 127;
uint32_t mantissa : 23 = 0;
}; // defaults to 1.0f
```
Things this change does not do:
- Align multiple comma-chained bitfield variables. None of the other
AlignConsecutive* options seem to implement that either.
- Detect bitfields that have a width specified with something other
than a numeric literal (ie, `int a : SOME_MACRO;`). That'd be fairly
difficult to parse and is rare.
Patch By: JakeMerdichAMD
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80176
Summary:
https://bugs.llvm.org/show_bug.cgi?id=43845
When a '//comment' trails a consecutive alignment, it adds a whitespace
replacement within the comment token. This wasn't handled correctly in
the alignment code, which treats it as a whole token and thus double
counts it.
This can wrongly trigger the "line too long, it'll wrap" alignment-break
condition with specific lengths, causing the alignment to break for
seemingly no reason.
Patch By: JakeMerdichAMD
Reviewed By: MyDeveloperDay
Subscribers: kostyakozko, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79465
Summary:
https://bugs.llvm.org/show_bug.cgi?id=45614
`[[nodiscard]]` after a macro doesn't behave the same as an __attribute__ resulting in incorrect indentation
This revision corrects that behavior
See original Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1629756
Before:
```
class FooWidget : public nsBaseWidget {
public:
FooWidget();
NS_DECL_ISUPPORTS_INHERITED
[[nodiscard]] nsresult
FunctionOne();
[[nodiscard]] nsresult FunctionTwo();
};
```
After:
```
class FooWidget : public nsBaseWidget {
public:
FooWidget();
NS_DECL_ISUPPORTS_INHERITED
[[nodiscard]] nsresult FunctionOne();
[[nodiscard]] nsresult FunctionTwo();
};
```
Reviewed By: Abpostelnicu
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79990
Summary:
https://bugs.llvm.org/show_bug.cgi?id=44476
```template <typename T> [[nodiscard]] int a() { return 1; }```
gets incorrectly formatted to be
```template <typename T>[[nodiscard]] int a() { return 1; }```
This revision ensure there is a space between the template and the attribute
Reviewed By: JakeMerdichAMD
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79905
Summary:
https://bugs.llvm.org/show_bug.cgi?id=45942
With Chromium style (although that is not important) its just it defines PointerAligmment: Left
The following arguments `S&&` are formatted differently depending on if the class has an attribute between it and the class identifier
```
class S {
S(S&&) = default;
};
class [[nodiscard]] S {
S(S &&) = default;
};
```
The prescense of [[nodiscard]] between the `class/struct` and the `{` causes the `{` to be incorrectly seen as a `TT_FunctionLBrace` which in turn transforms all the && to be `TT_BinaryOperators` rather than `TT_PointerOrReference`, as binary operators other spacing rules come into play causing a miss format
This revision resolves this by allowing the parseRecord to consider the [[nodisscard]]
Reviewed By: Abpostelnicu
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80008
Summary:
https://bugs.llvm.org/show_bug.cgi?id=44345
When namespaces get long the namespace end comment wraps onto the next line
```
namespace would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::
went::mad::now {
void foo();
void bar();
} // namespace
// would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::went::mad::now
```
If clang-format it applied successively it will duplicate the end comment
```
namespace would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::
went::mad::now {
void foo();
void bar();
} // namespace
// would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::went::mad::now
// would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::went::mad::now
```
This revision checks to ensure the end comment is not on the next line before adding yet another comment
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79935
Summary:
Even when BreakBeforeBinaryOperators is set, AlignOperands kept
aligning the beginning of the line, even when it could align the
actual operands (e.g. after an assignment).
With this patch, the operands are actually aligned, and the operator
gets aligned with the equal sign:
int aaaaa = bbbbbb
+ cccccc;
This not happen in tests, to avoid 'breaking' the indentation:
if (aaaaa
&& bbbbb)
return;
Reviewers: krasimir, djasper, klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, acoomans, cfe-commits, klimek
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D32478
Summary:
When multiple ternary operators are chained, e.g. like an if/else-if/
else-if/.../else sequence, clang-format will keep aligning the colon
with the question mark, which increases the indent for each
conditionals:
int a = condition1 ? result1
: condition2 ? result2
: condition3 ? result3
: result4;
This patch detects the situation (e.g. conditionals used in false branch
of another conditional), to avoid indenting in that case:
int a = condition1 ? result1
: condition2 ? result2
: condition3 ? result3
: result4;
When BreakBeforeTernaryOperators is false, this will format like this:
int a = condition1 ? result1 :
condition2 ? result2 :
conditino3 ? result3 :
result4;
This formatting style is referenced here:
https://www.fluentcpp.com/2018/02/27/replace-else-if-ternary-operator/
and here:
https://marcmutz.wordpress.com/2010/10/14/top-5-reasons-you-should-love-your-ternary-operator/
Reviewers: krasimir, djasper, klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: hokein, dyung, MyDeveloperDay, acoomans, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D50078
Summary:
Allow brace wrapping in C# property accessors to be controlled by configuration options.
Add new tests and revert old test results for Microsoft style to their previous state (as intended).
`FormatStyle.BraceWrapping.AfterFunction = true;` will change automatic property formatting from
```
Type MyType { get; set }
```
to
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir, MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D79000
Summary:
Currently the 'AlignConsecutive*' options incorrectly align across
elif and else statements, even if they are very far away and across
unrelated preprocessor macros.
This failed since on preprocessor run 2+, there is not enough context
about the #ifdefs to actually differentiate one block from another,
causing them to align across different blocks or even large sections of
the file.
Eg, with AlignConsecutiveAssignments:
```
\#if FOO // Run 1
\#else // Run 1
int a = 1; // Run 2, wrong
\#endif // Run 1
\#if FOO // Run 1
\#else // Run 1
int bar = 1; // Run 2
\#endif // Run 1
```
is read as
```
int a = 1; // Run 2, wrong
int bar = 1; // Run 2
```
The approach taken to fix this was to add a new flag to Token that
forces breaking alignment across groups of lines (MustBreakAlignBefore)
in a similar manner to the existing flag that forces a line break
(MustBreakBefore). This flag is set for the first Token after a
preprocessor statement or diff conflict marker.
Fixes #25167,#31281
Patch By: JakeMerdichAMD
Reviewed By: MyDeveloperDay
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79388
This enables us to intercept changes to the token type via setType(), which
is a precondition for being able to use multi-pass formatting for macro
arguments.
Differential Revision: https://reviews.llvm.org/D67405
Summary:
https://bugs.llvm.org/show_bug.cgi?id=45639
clang-format incorrectly splits the `[[` in a long argument list
```
void SomeLongClassName::ALongMethodNameInThatClass([[maybe_unused]] const shared_ptr<ALongTypeName>& argumentNameForThat
LongType) {
}
```
becomes
```
void SomeLongClassName::ALongMethodNameInThatClass([
[maybe_unused]] const shared_ptr<ALongTypeName> &argumentNameForThatLongType) {
}
```
leaving one `[` on the previous line
For a function with just 1 very long argument, clang-format chooses to split between the `[[`,
This revision prevents the slip between the two `[` and the second `[`
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79401
Summary: systemd recently added a clang-format file. One issue I
encountered in using clang-format on systemd is that systemd does
not add a space before the parens of their foreach macros but
clang-format always adds a space. This does not seem to be
configurable in clang-format. This revision adds the
ControlStatementsExceptForEachMacros option to SpaceBeforeParens
which puts a space before all control statement parens except
ForEach macros. This drastically reduces the amount of changes
when running clang-format on systemd's source code.
Reviewers: MyDeveloperDay, krasimir, mitchell-stellar
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78869
Summary: The condition added with the new setting checked whether the character was an l-brace, not specifically a lambda l-brace, when deciding whether it was possible to break before it or not. This caused the l-brace of some initialiser lists to break onto the next line with the first argument of the initialiser list when the setting was enabled.
Reviewed By: MyDeveloperDay, Wawha
Patch By: duncan-llvm
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79022
Summary:
Due to the order in which the enum cases were defined the old options which were retained for backwards compatibility were being preferred over the new options when printing with the --dump-config option.
Reviewers: MyDeveloperDay
Reviewed By: MyDeveloperDay
Patch By: duncan-llvm
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79020
Summary:
BTW my actual code that hit this issue is like
```
[a, b = std::move(b)](auto &&... c) mutable -> std::invoke_result_t<decltype(b), decltype(c)...> { /* omitted */ }
```
where this explicit return type is required for SFINAE.
Reviewed By: krasimir, MyDeveloperDay
Patch By: johnchen902
Subscribers: krasimir, dexonsmith, cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78694
Summary:
This is a tentative fix for https://bugs.llvm.org/show_bug.cgi?id=45357
Spaces seem to be introduced between * and * due to changes brought in for {D69573}
Reviewers: sylvestre.ledru, mitchell-stellar, sammccall, Abpostelnicu, krasimir, jbcoe
Reviewed By: Abpostelnicu
Subscribers: tstellar, hans, Abpostelnicu, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D78879
Summary:
Allow brace wrapping in C# property accessors to be controlled by configuration options.
Add new tests and revert old test results for MS style to their old state (as intended).
`FormatStyle.BraceWrapping.AfterFunction = true;` will change automatic property formatting from
```
Type MyType { get; set }
```
to
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D79000
Summary:
Added some examples of properties from Microsoft documentation as test cases.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties
Configuration support will be added in a follow up patch to address whether automatic properties are formatted as
```
Type MyType { get; set }
```
or
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78915
Summary: In recent patches the clang-format code has become un-formatted, correct this before making additional changes
Reviewers: mitchell-stellar, sylvestre.ledru, Abpostelnicu, Wawha, jbcoe
Reviewed By: sylvestre.ledru, Abpostelnicu, jbcoe
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D78909
Summary:
Improve C# `{ get; set; } = default;` formatting by handling it in the UnwrappedLineParser rather than trying to merge lines later.
Remove old logic to merge lines.
Update tests as formatting output has changed (as intended).
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78642
Summary:
Even when BreakBeforeBinaryOperators is set, AlignOperands kept
aligning the beginning of the line, even when it could align the
actual operands (e.g. after an assignment).
With this patch, there is an option to actually align the operands, so
that the operator gets right-aligned with the equal sign or return
operator:
int aaaaa = bbbbbb
+ cccccc;
return aaaaaaa
&& bbbbbbb;
This not happen in parentheses, to avoid 'breaking' the indentation:
if (aaaaa
&& bbbbb)
return;
Reviewers: krasimir, djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32478
When multiple ternary operators are chained, e.g. like an if/else-if/
else-if/.../else sequence, clang-format will keep aligning the colon
with the question mark, which increases the indent for each
conditionals:
int a = condition1 ? result1
: condition2 ? result2
: condition3 ? result3
: result4;
This patch detects the situation (e.g. conditionals used in false branch
of another conditional), to avoid indenting in that case:
int a = condition1 ? result1
: condition2 ? result2
: condition3 ? result3
: result4;
When BreakBeforeTernaryOperators is false, this will format like this:
int a = condition1 ? result1 :
condition2 ? result2 :
conditino3 ? result3 :
result4;
It can be used to avoid passing the begin and end of a range.
This makes the code shorter and it is consistent with another
wrappers we already have.
Differential revision: https://reviews.llvm.org/D78016
Summary:
Use spaces instead of tabs for alignment with UT_ForContinuationAndIndentation to make the code aligned for any tab/indent width.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38381
Reviewed By: MyDeveloperDay
Patch By: fickert
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D75034
Summary:
clang-format currently puts the first enumerator on the same line as the
enum keyword and opening brace if it fits (for example, for anonymous
enums if IndentWidth is 8):
$ echo "enum { RED, GREEN, BLUE };" | clang-format -style="{BasedOnStyle: llvm, ColumnLimit: 15, IndentWidth: 8}"
enum { RED,
GREEN,
BLUE };
This doesn't seem to be intentional, as I can't find any style guide that
suggests wrapping enums this way. Always force the enumerator to be on a new
line, which gets us the desired result:
$ echo "enum { RED, GREEN, BLUE };" | ./bin/clang-format -style="{BasedOnStyle: llvm, ColumnLimit: 15, IndentWidth: 8}"
enum {
RED,
GREEN,
BLUE
};
Test Plan:
New test added. Confirmed test failed without change and passed with change by
running:
$ ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewed By: MyDeveloperDay
Patch By: osandov
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D77682
Summary:
While [the original diff](https://reviews.llvm.org/D42493) makes a lot of sense, and multiple inline block parameter/trailing paramemter after inline block paramemter should be discouraged, the formatting result is different than what xcode does by default
For the exact same example provided in the original diff:
```
[object
blockArgument:^{
a = 42;
}
anotherArg:42];
```
The code is hard to read and not very visually pleasing
This diff uses `ObjCBreakBeforeNestedBlockParam` to shield from the formatting
When it's set to false, don't allign the inline block paramemters.
Reviewers: jolesiak, benhamilton, jinlin
Reviewed By: jolesiak
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77039
Summary:
The previous change in https://reviews.llvm.org/D77311 attempted to
detect more C++ keywords. However it also precisely detected all
JavaScript keywords. That's generally correct, but many JavaScripy
keywords, e.g. `get`, are so-called pseudo-keywords. They can be used in
positions where a keyword would never be legal, e.g. in a dotted
expression:
x.type; // type is a pseudo-keyword, but can be used here.
x.get; // same for get etc.
This change introduces an additional parameter to
`IsJavaScriptIdentifier`, allowing clients to toggle whether they want
to allow `IdentifierName` tokens, i.e. pseudo-keywords.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77548
Summary:
C++ defines a number of keywords that are regular identifiers in
JavaScript, e.g. `concept`:
const concept = 1; // legit JS
This change expands the existing `IsJavaScriptIdentifier(Tok)` function
to return false for C++ keywords that aren't keywords in JS.
Reviewers: krasimir
Subscribers: jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77311
Commit "[clang-format] Handle C# generic type constraints",
dcbcec4822
regressed the formatting of code containing `where` as an identifier in other
languages.
This fixes a regression from D69573 which broke the following example:
$ echo 'operator C<T>*();' | bin/clang-format --style=Chromium
operator C<T> *();
(There should be no space before the asterisk.)
It seems the problem is in TokenAnnotator::spaceRequiredBetween(),
which only looked at the token to the left of the * to see if it was a
type or not. That code only handled simple types or identifiers, not
templates or qualified types. This patch addresses that.
Differential revision: https://reviews.llvm.org/D76850
Summary:
Align sequential generic type constraints on a type.
Indent sequential generic type constraints on different types as continuations.
Do not allow '(' and '<' within a generic type constraint to open new scopes.
Reviewers: krasimir
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D76597
Summary:
Treat each C# generic type constraint, `where T: ...`, as a line.
Add C# keyword: where
Add Token Types: CSharpGenericTypeConstraint, CSharpGenericTypeConstraintColon, CSharpGenericTypeConstraintComma.
This patch does not wrap generic type constraints well, that will be addressed in a follow up patch.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D76367
Summary:
This diff extends the -style=file option to allow a config file to be specified explicitly. This is useful (for instance) when adding IDE commands to reformat code to a personal style.
Reviewers: djasper, ioeric, krasimir, MyDeveloperDay
Reviewed by: MyDeveloperDay
Contributed by: tnorth
Subscribers: cfe-commits, lebedev.ri, MyDeveloperDay, klimek, sammccall, mitchell-stellar
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D72326
Restores content of commit cb3f20d27c
reverted in commit 5a101f3773
with a corrected commit message.
Summary: Do not use continuation indent for '[' in blocks in C# code.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75747
Summary: Do not use continuation indent for '[' in blocks in C# code.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75747
Summary:
Disable merging of Type? into a single token.
Merge ?? ?. and ?[ into a single token.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75368
Summary:
Do not confuse C# nullable types with conditional expressions.
Do not put a space before the `?` in `[access-modifier] Type? variableName;`
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir, MyDeveloperDay
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75261
Summary:
No longer merge 'name' and ':' into a single token.
Ensure that line breaks cannot be placed before or after a named-argument colon.
Ensure that no space is inserted before a named-argument colon.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75244
Summary:
Ensure that there are spaces around braces '{', '}'.
Ensure that there is a space before and after '=>'.
Ensure that 'async' and 'when' are considered as keywords when inserting spaces.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D75129
Summary: Ensure that auto-implemented properties `{ get; private set }` are wrapped on to one line for C# code.
Reviewers: MyDeveloperDay, krasimir
Reviewed By: MyDeveloperDay, krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75006
Summary:
Merge 'argumentName' and ':' into a single token in foo(argumentName: bar).
Add C# named argument as a token type.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D74894
This option add a line break then a lambda is inside a function call.
Reviewers : djasper, klimek, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D44609
Summary:
C# attributes can appear on classes and methods, in which case they should go on their own line, or on method parameters in which case
they should be left inline.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: klimek
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D74265
Summary: Skip access specifiers before record definitions when deciding whether
or not to wrap lines so that C# class definitions do not get wrapped into a
single line.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D74050
Summary: Merge '[', 'target' , ':' into a single token for C# attributes to
prevent the target from being seen as a label.
Reviewers: MyDeveloperDay, krasimir
Reviewed By: krasimir
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D74043
Summary: Add comments to the list of tokens that can follow the ']' at the end of a C# attribute specifier to prevent comments after attribute specifiers from being formatted as continuations.
Reviewers: MyDeveloperDay, krasimir
Reviewed By: MyDeveloperDay
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D73977
Summary:
From `clang-format` version 3.7.0 and up, , there is no way to keep following format of ObjectiveC block:
```
- (void)_aMethod
{
[self.test1 t:self w:self callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
u = c;
}]
}
```
Regardless of the change in `.clang-format` configuration file, all parameters will be lined up so that colons will be on the same column, like following:
```
- (void)_aMethod
{
[self.test1 t:self
w:self
callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
u = c;
}]
}
```
Considering with ObjectiveC, the first code style is cleaner & more readable for some people, I've added a config option: `ObjCDontBreakBeforeNestedBlockParam` (boolean) so that if it is enable, the first code style will be favored.
Reviewed By: MyDeveloperDay
Patch By: ghvg1313
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D70926
Summary:
This change adds an option to insert trailing commas into container
literals. For example, in JavaScript:
const x = [
a,
b,
^~~~~ inserted if missing.
]
This is implemented as a seperate post-processing pass after formatting
(because formatting might change whether the container literal does or
does not wrap). This keeps the code relatively simple and orthogonal,
though it has the notable drawback that the newly inserted comma is not
taken into account for formatting decisions (e.g. it might exceed the 80
char limit). To avoid exceeding the ColumnLimit, a comma is only
inserted if it fits into the limit.
Trailing comma insertion conceptually conflicts with argument
bin-packing: inserting a comma disables bin-packing, so we cannot do
both. clang-format rejects FormatStyle configurations that do both with
this change.
Reviewers: krasimir, MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Summary:
This addresses issues raised in https://bugs.llvm.org/show_bug.cgi?id=44454.
There are outstanding issues with multi-line verbatim strings in C# that will be addressed in a follow-up PR.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir, MyDeveloperDay
Subscribers: MyDeveloperDay
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D73492
Summary:
clang-format currently always wraps the body of non-empty arrow
functions:
const x = () => {
z();
};
This change implements support for the `AllowShortLambdasOnASingleLine`
style options, controlling the indent style for arrow function bodies
that have one or fewer statements. SLS_All puts all on a single line,
SLS_Inline only arrow functions used in an inline position.
const x = () => { z(); };
Multi-statement arrow functions continue to be wrapped. Function
expressions (`a = function() {}`) and function/method declarations are
unaffected as well.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73335
Summary:
An heuristic targetting `x && x->foo` was targed overly broadly and caused the
last T&& to be treated as a binary operator.
Reviewers: hokein
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73334
Contributed by jbcoe!
Summary: Unless SpaceBeforeParensOptions is set to SBPO_Never, a space will be put between `using` and `(` in C# code.
Reviewers: klimek, MyDeveloperDay, krasimir
Reviewed By: krasimir
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D72144
Summary:
clang-format currently treats the nullish coalescing operator `??` like
the ternary operator. That causes multiple nullish terms to be each
indented relative to the last `??`, as they would in a ternary.
The `??` operator is often used in chains though, and as such more
similar to other binary operators, such as `||`. So to fix the indent,
set its token type to `||`, so it inherits the same treatment.
This opens up the question of operator precedence. However, `??` is
required to be parenthesized when mixed with `||` and `&&`, so this is
not a problem that can come up in syntactically legal code.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73026
Summary: This diff expands the SpacesAroundConditions option added in D68346 to include adding spaces to catch statements.
Reviewed By: MyDeveloperDay
Patch by: timwoj
Differential Revision: https://reviews.llvm.org/D72793
Summary:
The documentation for IndentCaseLabels claimed that the "Switch
statement body is always indented one level more than case labels". This
is technically false for the code block immediately following the label.
Its closing bracket aligns with the start of the label.
If the case label are not indented, it leads to a style where the
closing bracket of the block aligns with the closing bracket of the
switch statement, which can be hard to parse.
This change introduces a new option, IndentCaseBlocks, which when true
treats the block as a scope block (which it technically is).
(Note: regenerated ClangFormatStyleOptions.rst using tools/dump_style.py)
Reviewed By: MyDeveloperDay
Patch By: capn
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D72276
Summary:
tslint and tsc (the TypeScript compiler itself) use comment pragmas of
the style:
// tslint:disable-next-line:foo
// @ts-ignore
These must not be wrapped and must stay on their own line, in isolation.
For tslint, this required adding it to the pragma regexp. The comments
starting with `@` are already left alone, but this change adds test
coverage for them.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72907
Summary:
Revision a75f8d98d7 fixed spacing for operators,
but caused the const and non-const versions to diverge:
```
// With Style.PointerAlignment = FormatStyle::PAS_Left:
struct A {
operator char*() { return ""; }
operator const char *() const { return ""; }
};
```
The code was checking if the type specifier was directly preceded by `operator`.
However there could be comments and `const/volatile` in between.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72911
Summary:
Including `do`, `for`, and `while`, `if`, `else`, `try`, `catch`, in
addition to the previously handled fields. The unit test explicitly uses
methods, but this code path handles both fields and methods.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72827
Summary:
Found a bug introduced with BraceWrappingFlags AfterControlStatement MultiLine. This feature conflicts with the existing BeforeCatch and BeforeElse flags.
For example, our team uses BeforeElse.
if (foo ||
bar) {
doSomething();
}
else {
doSomethingElse();
}
If we enable MultiLine (which we'd really love to do) we expect it to work like this:
if (foo ||
bar)
{
doSomething();
}
else {
doSomethingElse();
}
What we actually get is:
if (foo ||
bar)
{
doSomething();
}
else
{
doSomethingElse();
}
Reviewers: MyDeveloperDay, Bouska, mitchell-stellar
Patch by: pastey
Subscribers: Bouska, cfe-commits
Tags: clang
Differential Revision: https://reviews.llvm.org/D71939
Before:
class Foo {
@CommandLineFlags
.Add
@Features.foo
public void test() {}
}
Now:
class Foo {
@Features.foo
@CommandLineFlags.Add
public void test() { }
}
See also https://crbug.com/1034115
Summary:
https://bugs.llvm.org/show_bug.cgi?id=44340
The rule that prevents `... {} [[....]]` being treated as a braced initializer for C++ causes problems for C# with attributes, causing it to be incorrectly classified and then messing up the subsequent formatting. (see bug for details of formatting)
Reviewers: mitchell-stellar, klimek, sammccall
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D71769
Summary:
As a followup to D69144, this diff fixes the coroutine keyword spacing
for co_yield / co_returning negative numbers.
Reviewers: modocache, sammccall, Quuxplusone
Reviewed By: modocache
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69180
Patch by Jonathan Thomas (jonathoma)!
The const-correctness of match() was fixed in rL372764, which allows
uses of Regex objects to be const in cases they couldn't be before. This
patch tightens up the const-ness of Regex in various such cases.
Reviewers: thopre
Reviewed By: thopre
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68155
Summary: Adds a new option SpaceBeforeBrackets to add spaces before brackets (i.e. int a[23]; -> int a [23];) This is present as an option in the Visual Studio C++ code formatting settings, but there was no matching setting in clang-format.
Reviewers: djasper, MyDeveloperDay, mitchell-stellar
Reviewed By: MyDeveloperDay
Subscribers: llvm-commits, cfe-commits, klimek
Patch by: Anteru
Tags: #clang, #clang-format, #llvm
Differential Revision: https://reviews.llvm.org/D6920
Line ending detection is now set with the `DeriveLineEnding` option.
CRLF can now be used as the default line ending by setting `UseCRLF`.
When line ending detection is disabled, all line endings are converted
according to the `UseCRLF` option.
Differential Revision: https://reviews.llvm.org/D19031
Summary:
By additional regex match, grouping of main include can be enabled in files that are not normally considered as a C/C++ source code.
For example, this might be useful in templated code, where template implementations are being held in *Impl.hpp files.
On the occassion, 'assume-filename' option description was reworded as it was misleading. It has nothing to do with `style=file` option and it does not influence sourced style filename.
Reviewers: rsmith, ioeric, krasimir, sylvestre.ledru, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch by: furdyna
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67750
Summary:
JavaScript / TypeScript is adding two new operators: the null
propagating operator `?.` and the nullish coalescing operator `??`.
const x = foo ?? 'default';
const z = foo?.bar?.baz;
This change adds support to lex and format both.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69971
Summary:
This fixes an edge case in the `SpacesInSquareBrackets` option where an initial `&ref` lambda parameter is not padded with an initial space.
`int foo = [&bar ]() {}` is fixed to give `int foo = [ &bar ]() {}`
Reviewers: MyDeveloperDay, klimek, sammccall
Reviewed by: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D69649
Summary:
The code `throw -1;` is currently formatted by clang-format as
`throw - 1;`. This diff adds a fix for this edge case and a test to check
for this in the future.
For context, I am looking into a related bug in the clang-formatting of
coroutine keywords: `co_yield -1;` is also reformatted in this manner
as `co_yield - 1;`. A later diff will add these changes and tests for the
`co_yield` and `co_return` keywords.
Patch by Jonathan Thomas (jonathoma)!
Reviewers: modocache, sammccall, Quuxplusone
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D69144
llvm-svn: 375258
Summary:
r373922 added checks for a few tokens that, following an `)` make it
unlikely that the `)` is the closing paren of a cast expression. The
specific check for `tok::l_square` there introduced a regression for
casts of Obj-C calls, like:
```
(cast)[func arg]
```
From the tests added in r373922, I believe the `tok::l_square` case is added to
capture the case where a non-cast `)` is directly followed by an
attribute specifier, like:
```
int f(int x) [[noreturn]];
```
I've specialized the code to look for such attribute specifier instead
of `tok::l_square` in general. Also, I added a regression test and moved
the test cases added in r373922 to an already existing place documenting
other instances of historically misidentified casts.
Reviewers: MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69164
llvm-svn: 375247
Summary:
r373165 fixed an issue where a templated noexcept member function with a
reference qualifier would be indented more than expected:
```
// Formatting produced with LLVM style with AlwaysBreakTemplateDeclarations: Yes
// before r373165:
struct f {
template <class T>
void bar() && noexcept {}
};
// after:
struct f {
template <class T>
void bar() && noexcept {}
};
```
The way this is done is that in the AnnotatingParser in
`lib/FormatTokenAnnotator.cpp` the determination of the usage of a `&` or `&&`
(the line in determineTokenType
```
Current.Type = determineStarAmpUsage(...
```
is not performed in some cases anymore, combining with a few additional related
checks afterwards. The net effect of these checks results in the `&` or `&&`
token to start being classified as `TT_Unknown` in cases where before `r373165`
it would be classified as `TT_UnaryOperator` or `TT_PointerOrReference` by
`determineStarAmpUsage`.
This inadvertently caused 2 classes of regressions I'm aware of:
- The address-of `&` after a function assignment would be classified as
`TT_Unknown`, causing spaces to surround it, disregarding style options:
```
// before r373165:
void (*fun_ptr)(void) = &fun;
// after:
void (*fun_ptr)(void) = & fun;
```
- In cases where there is a function declaration list -- looking macro between
a template line and the start of the function declaration, an `&` as part of
the return type would be classified as `TT_Unknown`, causing spaces to
surround it:
```
// before r373165:
template <class T>
DEPRECATED("lala")
Type& foo();
// after:
template <class T>
DEPRECATED("lala")
Type & foo();
```
In these cases the problems are rooted in the skipping of the classification of
a `&` (and similarly `&&`) by determineStarAmpUsage which effects the formatting
decisions later in the pipeline.
I've looked into the goal of r373165 and noticed that replacing `noexcept` with
`const` in the given example produces no extra indentation with the old code:
```
// before r373165:
struct f {
template <class T>
int foo() & const {}
};
struct f {
template <class T>
int foo() & noexcept {}
};
```
I investigated how clang-format annotated these two examples differently to
determine the places where the processing of both diverges in the pipeline.
There were two places where the processing diverges, causing the extra indent in
the `noexcept` case:
1. The `const` is annotated as a `TT_TrailingAnnotation`, whereas `noexcept`
is annotated as `TT_Unknown`. I've updated the `determineTokenType` function
to account for this by adding a missing `tok:kw_noexcept` to the clause that
marks a token as `TT_TrailingAnnotation`.
2. The `&` in the second example is wrongly identified as `TT_BinaryOperator`
in `determineStarAmpUsage`. This is the reason for the extra indentation --
clang-format gets confused and thinks this is an expression.
I've updated `determineStarAmpUsage` to check for `tok:kw_noexcept`.
With these two updates in place, the additional parsing introduced by r373165
becomes unnecessary and all added tests pass (with updates, as now clang-format
respects the style configuration for spaces around the `&` in the test
examples).
I've removed these additions and added regression tests for the cases above.
Reviewers: AndWass, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D68695
llvm-svn: 374172
Summary:
clang-format is incorrectly thinking the parameter parens are part of a cast operation, this is resulting in there sometimes being not space between the paren and the noexcept (and other keywords like volatile etc..)
```
void operator++(int) noexcept;
void operator++(int &) noexcept;
void operator delete(void *, std::size_t, const std::nothrow_t &)noexcept;
```
Reviewers: klimek, owenpan, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68481
llvm-svn: 373922
Summary:
This patch makes the `SpacesInSquareBrackets` setting also apply to C++ lambdas with parameters.
Looking through the revision history, it appears support for only array brackets was added, and lambda brackets were ignored. Therefore, I am inclined to think it was simply an omission, rather than a deliberate choice.
See https://bugs.llvm.org/show_bug.cgi?id=17887 and https://reviews.llvm.org/D4944.
Reviewers: MyDeveloperDay, reuk, owenpan
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Patch by: mitchell-stellar
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68473
llvm-svn: 373821
Summary:
According to the clang-format documentation, "Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place. If the braced list follows a name (e.g. a type or variable name), clang-format formats as if the `{}` were the parentheses of a function call with that name."
This patch furthers the treatment of C++11 braced list braces as parentheses by respecting the `SpacesInParentheses` setting.
Reviewers: MyDeveloperDay, reuk, owenpan
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Patch By: mitchell-stellar
Differential Revision: https://reviews.llvm.org/D68415
llvm-svn: 373751
Summary:
https://bugs.llvm.org/show_bug.cgi?id=43531
Fix for clang-format incorrectly handles "alternative operators" as described by https://en.cppreference.com/w/cpp/language/operator_alternative
compl = ~
not = !
these are unary operators, and clang-format will remove the space between them and a numeric constant
this incorrectly formats the following code
```
int a compl 5;
int a not 5;
```
into:
```
int a compl5;
int a not5;
```
The code adds FIXME unit tests for "alternative token" representations for {} [] and # as defined by the same link, which would require a more detailed change to the FormatTokenLexer
Reviewers: klimek, reuk, owenpan, mitchell-stellar, STL_MSFT
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D68332
llvm-svn: 373750
Summary:
https://bugs.llvm.org/show_bug.cgi?id=42417
This revision removes the extra space between the opertor-> and the parens ()
```
class Bug {
auto operator-> () -> int*;
auto operator++(int) -> int;
};
```
Reviewers: klimek, owenpan, byoungyoung, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68242
llvm-svn: 373746
Summary:
When formatting C# there can be issues with a lack of spaces between `using (` , `foreach (` and generic types
The C# code
```
public class Foo
{
Dictionary<string,string> foo;
}
```
will be formatted as
```
public class Foo
{
Dictionary<string, string>foo;
^^^^^ missing a space
}
```
This revision also reverts some of {D66662} in order to make this cleaner and resolve an issues seen by @owenpan that the formatting didn't add a space when not in a code block
This also transforms C# foreach commands to be seen as tok::kw_for commands (to ensure foreach gets the same Brace Wrapping behavior as for without littering the code with `if(Style.isCSharp())`
Reviewers: owenpan, klimek, russellmcc, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D67660
llvm-svn: 373709
Summary:
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=43333
This comes with 3 main parts
- C# attributes cause function names on a new line even when AlwaysBreakAfterReturnType is set to None
- Add AlwaysBreakAfterReturnType to None by default in the Microsoft style,
- C# unit tests are not using Microsoft style (which we created to define the default C# style to match a vanilla C# project).
Reviewers: owenpan, klimek, russellmcc, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-tools-extra, #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D67629
llvm-svn: 373707
Summary:
Change the BraceWrappingFlags' AfterControlStatement from a bool to an enum with three values:
* "Never": This is the default, and does not do any brace wrapping after control statements.
* "MultiLine": This only wraps braces after multi-line control statements (this really only happens when a ColumnLimit is specified).
* "Always": This always wraps braces after control statements.
The first and last options are backwards-compatible with "false" and "true", respectively.
The new "MultiLine" option is useful for when a wrapped control statement's indentation matches the subsequent block's indentation. It makes it easier to see at a glance where the control statement ends and where the block's code begins. For example:
```
if (
foo
&& bar )
{
baz();
}
```
vs.
```
if (
foo
&& bar ) {
baz();
}
```
Short control statements (1 line) do not wrap the brace to the next line, e.g.
```
if (foo) {
bar();
} else {
baz();
}
```
Reviewers: sammccall, owenpan, reuk, MyDeveloperDay, klimek
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch By: mitchell-stellar
Tags: #clang-format, #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D68296
llvm-svn: 373647
Summary:
The historical context:
- clang-format was written when C++11 was current,
and the main language-version concern was >> vs > > template-closers.
An option was added to allow selection of the 03/11 behavior, or auto-detection.
- there was no option to choose simply "latest standard" so anyone who didn't
ever want 03 behavior or auto-detection specified Cpp11.
- In r185149 this option started to affect lexer mode.
- no options were added to cover c++14, as parsing/formatting
didn't change that much. The usage of Cpp11 to mean "latest" became
codified e.g. in r206263
- c++17 added some new constructs. These were mostly backwards-compatible and so
not used in old programs, so having no way to turn them off was OK.
- c++20 added some new constructs and keywords (e.g. co_*) that changed the
meaning of existing programs, and people started to complain that
the c++20 parsing couldn't be turned off.
New plan:
- Default ('Auto') behavior remains unchanged: parse as latest, format
template-closers based on input.
- Add new 'Latest' option that more clearly expresses the intent "use
modern features" that many projects have chosen for their .clang-format files.
- Allow pinning to *any* language version, using the same name as clang -std:
c++03, c++11, c++14 etc. These set precise lexer options, and any
clang-format code depending on these can use a >= check.
- For backwards compatibility, `Cpp11` is an alias for `Latest`, not `c++11`.
This matches the historical documented semantics of this option.
This spelling (and `Cpp03`) are deprecated.
Reviewers: klimek, modocache
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67541
llvm-svn: 373439
Summary:
This is a patch to fix PR43372 (https://bugs.llvm.org/show_bug.cgi?id=43372) - clang-format can't format file with includes, ( which really keep providing replacements for already sorted headers.)
A similar issue was addressed by @krasimir in {D60199}, however, this seemingly only prevented the issue when the files being formatted did not contain windows line endings (\r\n)
It's possible this is related to https://twitter.com/StephanTLavavej/status/1176722938243895296 given who @STL_MSFT works for!
As people often used the existence of replacements to determine if a file needs clang-formatting, this is probably pretty important for windows users
There may be a better way of comparing 2 strings and ignoring \r (which appear in both Results and Code), I couldn't choose between this idiom or the copy_if approach, but I'm happy to change it to whatever people consider more performant.
Reviewers: krasimir, klimek, owenpan, ioeric
Reviewed By: krasimir
Subscribers: cfe-commits, STL_MSFT, krasimir
Tags: #clang-format, #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D68227
llvm-svn: 373388
Summary:
The following code
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
will be formatted to the following with LLVM style, and
`AlwaysBreakTemplateDeclarations: Yes`
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
The indentation of the `void bar()` line is wrong.
Reviewers: klimek, owenpan, krasimir, timwoj, MyDeveloperDay
Reviewed By: klimek, MyDeveloperDay
Subscribers: MyDeveloperDay, ilya-biryukov, llvm-commits, cfe-commits
Patch By: AndWass
Tags: #clang-format, #clang, #llvm
Differential Revision: https://reviews.llvm.org/D68072
llvm-svn: 373165
The following code
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
will be formatted to the following with LLVM style, and
`AlwaysBreakTemplateDeclarations: Yes`
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
The indentation of the `void bar()` line is wrong.
Patch by Andreas Wass (AndWass)!
Differential Revision: https://reviews.llvm.org/D68072
llvm-svn: 373056
Summary:
This new Style rule is made as a part of adding support for NetBSD KNF in clang-format. NetBSD have it's own priority of includes which should be followed while formatting NetBSD code. This style sorts the Cpp Includes according to the priorities of NetBSD, as mentioned in the [Style Guide](http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style?rev=HEAD&content-type=text/x-cvsweb-markup)
The working of this Style rule shown below:
**Configuration:**
This revision introduces a new field under IncludeCategories named `SortPriority` which defines the priority of ordering the `#includes` and the `Priority` will define the categories for grouping the `#include blocks`.
Reviewers: cfe-commits, mgorny, christos, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: lebedev.ri, rdwampler, christos, mgorny, krytarowski
Patch By: Manikishan
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D64695
llvm-svn: 372919
Summary:
This patch adds support for the Whitesmiths indentation style to clang-format. It’s an update to a patch submitted in 2015 (D6833), but reworks it to use the newer API.
There are still some issues with this patch, primarily around `switch` and `case` support. The added unit test won’t currently pass because of the remaining issues.
Reviewers: mboehme, MyDeveloperDay, djasper
Reviewed By: MyDeveloperDay
Subscribers: krasimir, MyDeveloperDay, echristo, cfe-commits
Patch By: @timwoj (Tim Wojtulewicz)
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67627
llvm-svn: 372497
Summary:
https://bugs.llvm.org/show_bug.cgi?id=41899
```auto lambda = [&a = a]() { a = 2; };```
is formatted as
```auto lambda = [& a = a]() { a = 2; };```
With an extra space if PointerAlignment is set to Left
> The space "& a" looks strange when there is no type in the lambda's intializer expression. This can be worked around with by setting "PointerAlignment: Right", but ideally "PointerAlignment: Left" would not add a space in this case.
Reviewers: klimek, owenpan, krasimir, timwoj
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D67718
llvm-svn: 372249
Summary:
AnnotatedLine has a tree structure, and things like the body of a lambda will be
a child of the lambda expression. For example,
[&]() { foo(a); };
will have an AnnotatedLine with a child:
[&]() {};
'- foo(a);
Currently, when the `Cleaner` class analyzes the affected lines, it does not
cleanup the lines' children nodes, which results in missed cleanup
opportunities, like the lambda body in the example above.
This revision extends the algorithm to visit children, thereby fixing the above problem.
Patch by Eric Li.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67659
llvm-svn: 372129
This patch makes cases work where the lambda's template list doesn't
contain any of + - ! ~ / % << | || && ^ == != >= <= ? : true false
(see added FIXME).
Ports r359967 to clang-format.
Differential Revision: https://reviews.llvm.org/D67246
llvm-svn: 371854
Summary:
Addresses https://bugs.llvm.org/show_bug.cgi?id=43100
Formatting using statement in C# with clang-format removes the space between using and paren even when SpaceBeforeParens is !
```
using(FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize : 1))
```
this change simply overcomes this for when using C# settings in the .clang-format file
```
using (FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize : 1))
```
All FormatTests pass..
```
[==========] 688 tests from 21 test cases ran. (88508 ms total)
[ PASSED ] 688 tests.
```
Reviewers: djasper, klimek, owenpan
Reviewed By: owenpan
Subscribers: llvm-commits, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66662
llvm-svn: 371720
Summary:
This option determines whether goto labels are indented according to scope. Setting this option to false causes goto labels to be flushed to the left.
This is mostly copied from [[ http://lists.llvm.org/pipermail/cfe-dev/2015-September/045014.html | this patch ]] submitted by Christian Neukirchen that didn't make its way into trunk.
```
true: false:
int f() { vs. int f() {
if (foo()) { if (foo()) {
label1: label1:
bar(); bar();
} }
label2: label2:
return 1; return 1;
} }
```
Reviewers: klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-tools-extra
Patch by: tetsuo-cpp
Differential Revision: https://reviews.llvm.org/D67037
llvm-svn: 371719
Summary:
TypeScript 3.4 supports casting into a const type using `as const`:
const x = {x: 1} as const;
Previously, clang-format would insert a space after the `const`. With
this patch, no space is inserted after the sequence `as const`.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66736
llvm-svn: 369916
PR43085.
Recognize .mjs files as JavaScript. .mjs is the extension for ECMAScript modules.
A specific extension (and associated content type javascript/esm) is
introduced to differentiate it from CommonJS modules and solve some
interoperability problems.
Differential Revision: https://reviews.llvm.org/D66584
Patch by Fergal Daly
llvm-svn: 369732
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
Summary:
This (invalid) fragment is crashing clang-format:
```
#if 1
int x;
#elif
int y;
#endif
```
The reason being that the parser expects a token after `#elif`, and the
subsequent parsing of the next line does not check if `CurrentToken` is null.
Reviewers: gribozavr
Reviewed By: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65940
llvm-svn: 368280
This is like r305666 (which added support for `if constexpr`) except
that it allows a macro name after the if.
This is slightly tricky for two reasons:
1. r305666 didn't add test coverage for all cases where it added a
kw_constexpr, so I had to figure out what all the added cases were
for. I now added tests for all `if constexpr` bits that didn't have
tests. (This took a while, see e.g. https://reviews.llvm.org/D65223)
2. Parsing `if <ident> (` as an if means that `#if defined(` and
`#if __has_include(` parse as ifs too. Add some special-case code
to prevent this from happening where it's incorrect.
Fixes PR39248.
Differential Revision: https://reviews.llvm.org/D65227
llvm-svn: 367167
Preparatory change for D65043.
We current use `!=LS_Cpp03` to enable language standards 11,14,17, and
2a. `>=LS_Cpp11` is better if we decide to add new LanguageStandard in
the future.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D65183
llvm-svn: 366876
Summary:
Previously, clang-format detected something like the following as a C++11 attribute specifier.
@[[NSArray class]]
instead of an array with an Objective-C method call inside. In general, when the attribute specifier checking runs, if it sees 2 identifiers in a row, it decides that the square brackets represent an Objective-C method call. However, here, `class` is tokenized as a keyword instead of an identifier, so this check fails.
To fix this, the attribute specifier first checks whether the first square bracket has an "@" before it. If it does, then that square bracket is not the start of a attribute specifier because it is an Objective-C array literal. (The assumption is that @[[.*]] is not valid C/C++.)
Contributed by rkgibson2.
Reviewers: benhamilton
Reviewed By: benhamilton
Subscribers: aaron.ballman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64632
llvm-svn: 366267
This option behaves similarly to AlignConsecutiveDeclarations and
AlignConsecutiveAssignments, aligning the assignment of C/C++
preprocessor macros on consecutive lines.
I've worked in many projects (embedded, mostly) where header files full
of large, well-aligned "#define" blocks are a common pattern. We
normally avoid using clang-format on these files, since it ruins any
existing alignment in said blocks. This style option will align "simple"
PP macros (no parameters) and PP macros with parameter lists on
consecutive lines.
Related Bugzilla entry (thanks mcuddie):
https://llvm.org/bugs/show_bug.cgi?id=20637
Patch by Nick Renieris (VelocityRa)!
Differential Revision: https://reviews.llvm.org/D28462
llvm-svn: 364938
Summary:
Other macros are used to declare namespaces, and should thus be handled
similarly. This is the case for crpcut's TESTSUITE macro, or for
unittest-cpp's SUITE macro:
TESTSUITE(Foo) {
TEST(MyFirstTest) {
assert(0);
}
} // TESTSUITE(Foo)
This patch deals with this cases by introducing a new option to specify
lists of namespace macros. Internally, it re-uses the system already in
place for foreach and statement macros, to ensure there is no impact on
performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: klimek
Subscribers: acoomans, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37813
llvm-svn: 362740
Summary:
Adds a `TypenameMacros` configuration option that causes certain identifiers to be handled in a way similar to `typeof()`.
This is enough to:
- Prevent misinterpreting declarations of pointers to such types as expressions (`STACK_OF(int) * foo` -> `STACK_OF(int) *foo`),
- Avoid surprising line breaks in variable/struct field declarations (`STACK_OF(int)\nfoo;` -> `STACK_OF(int) foo;`, see https://bugs.llvm.org/show_bug.cgi?id=30353).
Reviewers: Typz, krasimir, djasper
Reviewed By: Typz
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57184
llvm-svn: 361986
Summary:
Top-level "package" and "import" statements should generally be kept on
one line, for all languages.
----
This reverts commit rL356912.
The regression from rL356835 was fixed via rC358275.
Reviewers: krasimir, sammccall, MyDeveloperDay, xinz, dchai, klimek
Reviewed By: krasimir, xinz, dchai
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60661
llvm-svn: 360411
Björn Schäpers