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 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:
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
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:
This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas.
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57687
llvm-svn: 357027
Summary:
This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.
Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850
Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.
I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..)
Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile.
Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.
Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted.
Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth
Reviewed By: klimek
Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58404
llvm-svn: 356662
Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010
Code like:
```
if(true) var++;
else {
var--;
}
```
is reformatted to be
```
if (true)
var++;
else {
var--;
}
```
Even when `AllowShortIfStatementsOnASingleLine` is true
The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine
This suppresses the clause prevents the merging of the if when there is a compound else
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087
llvm-svn: 356031
Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010
Code like:
```
if(true) var++;
else {
var--;
}
```
is reformatted to be
```
if (true)
var++;
else {
var--;
}
```
Even when `AllowShortIfStatementsOnASingleLine` is true
The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine
This suppresses the clause prevents the merging of the if when there is a compound else
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087
llvm-svn: 356029
I assume the example is wrong as it's clearly missing line-breaks before
braces.
I just ran the example through clang-format with .clang-format like
this:
BreakBeforeBraces: Allman
Differential Revision: https://reviews.llvm.org/D58941
llvm-svn: 355365
Summary:
Some macros are used in the body of function, and actually contain the trailing semicolon: they should thus be automatically followed by a new line, and not get merged with the next line. This is for example the case with Qt's Q_UNUSED macro:
void foo(int a, int b) {
Q_UNUSED(a)
return b;
}
This patch deals with these cases by introducing a new option to specify list of statement macros. This re-uses the system already in place for foreach macros, to ensure there is no impact on performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: krasimir
Subscribers: acoomans, mgrang, alexfh, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33440
llvm-svn: 343602
Summary:
Extend the Clang-Format IncludeCategories documentation by adding a link to the supported regular expression standard (POSIX).
And extenting the example with a system header regex.
[[ https://bugs.llvm.org/show_bug.cgi?id=35041 | bug 35041]]
Contributed by WimLeflere!
Reviewers: krasimir, Typz
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48827
llvm-svn: 337899
Summary:
It seems that the changes done to `ClangFormatStyleOptions.rst` @334408 are causing the generation of the documentation to fail, with the following error:
Warning, treated as error:
/llvm/tools/clang/docs/ClangFormatStyleOptions.rst:1060: WARNING: Definition list ends without a blank line; unexpected unindent.
This is due to missing indent in some code block, and fixed by this patch.
Reviewers: krasimir, djasper, klimek
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48161
llvm-svn: 334709
WebKit C++ style for object initialization is as follows:
Foo foo { bar };
Yet using clang-format -style=webkit changes this to:
Foo foo{ bar };
As there is no existing combination of rules that will ensure a space
before a braced list in this fashion, this patch adds a new
SpaceBeforeCpp11BracedList rule.
Patch by Ross Kirsling!
Differential Revision: https://reviews.llvm.org/D46024
llvm-svn: 334692
Summary:
This option replaces the BreakBeforeInheritanceComma option with an
enum, thus introducing a mode where the colon stays on the same line as
constructor declaration:
// When it fits on line:
class A : public B, public C {
...
};
// When it does not fit:
class A :
public B,
public C {
...
};
This matches the behavior of the `BreakConstructorInitializers` option,
introduced in https://reviews.llvm.org/D32479.
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: mzeren-vmw, cfe-commits
Differential Revision: https://reviews.llvm.org/D43015
llvm-svn: 334408
Summary:
Introduce `PenaltyBreakTemplateDeclaration` to control the penalty,
and change `AlwaysBreakTemplateDeclarations` to an enum with 3 modes:
* `No` for regular, penalty based, wrapping of template declaration
* `MultiLine` for always wrapping before multi-line declarations (e.g.
same as legacy behavior when `AlwaysBreakTemplateDeclarations=false`)
* `Yes` for always wrapping (e.g. same as legacy behavior when
`AlwaysBreakTemplateDeclarations=true`)
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42684
llvm-svn: 332436
Patch contributed by @EricMarti!
Summary: I noticed that the example for SpaceAfterCStyleCast does not match its description. I fixed the example after testing it out.
Reviewers: rsmith, krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43731
llvm-svn: 326781
Summary:
When disabled, this option allows removing the space before colon,
making it act more like the semi-colon. When enabled (default), the
current behavior is not affected.
This mostly affects C++11 loop, initializer list, inheritance list and
container literals:
class Foo: Bar {}
Foo::Foo(): a(a) {}
for (auto i: myList) {}
f({a: 1, b: 2, c: 3});
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: xvallspl, teemperor, karies, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32525
llvm-svn: 326426
Summary:
This patch adds canonical delimiter support to the raw string formatting.
This allows matching delimiters to be updated to the canonical one.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42187
llvm-svn: 322956
Summary:
This patch allows grouping multiple #include blocks together and sort all includes as one big block.
Additionally, sorted includes can be regrouped after sorting based on configured categories.
Contributed by @KrzysztofKapusta!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D40288
llvm-svn: 319024
Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **"extern C part"**
**Problem:**
Due to the lack of "brace wrapping extern" flag, clang format does parse the block after **extern** keyword moving the opening bracket to the header line always!
**Patch description:**
A new style added, new configuration flag - **BraceWrapping.AfterExternBlock** that allows us to decide whether we want a break before brace or not.
Reviewers: djasper, krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37845
Contributed by @PriMee!
llvm-svn: 313354
The current description of AllowAllParametersOfDeclarationOnNextLine in
the Clang-Format Style Options guide suggests that it is possible to
format function declaration, which fits in a single line (what is not
supported in current clang-format version). Also the example was not
reproducible and mades no sense.
Patch by Lucja Mazur, thank you!
llvm-svn: 312721
Summary:
Looks like we are out of sync between the doc and the code.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37558
llvm-svn: 312716
Summary:
This is an implementation for [bug 17362](https://bugs.llvm.org/attachment.cgi?bugid=17362) which adds support for indenting preprocessor statements inside if/ifdef/endif. This takes previous work from fmauch (https://github.com/fmauch/clang/tree/preprocessor_indent) and makes it into a full feature.
The context of this patch is that I'm a VMware intern, and I implemented this because VMware needs the feature. As such, some decisions were made based on what VMware wants, and I would appreciate suggestions on expanding this if necessary to use-cases other people may want.
This adds a new enum config option, `IndentPPDirectives`. Values are:
* `PPDIS_None` (in config: `None`):
```
#if FOO
#if BAR
#include <foo>
#endif
#endif
```
* `PPDIS_AfterHash` (in config: `AfterHash`):
```
#if FOO
# if BAR
# include <foo>
# endif
#endif
```
This is meant to work whether spaces or tabs are used for indentation. Preprocessor indentation is independent of indentation for non-preprocessor lines.
Preprocessor indentation also attempts to ignore include guards with the checks:
1. Include guards cover the entire file
2. Include guards don't have `#else`
3. Include guards begin with
```
#ifndef <var>
#define <var>
```
This patch allows `UnwrappedLineParser::PPBranchLevel` to be decremented to -1 (the initial value is -1) so the variable can be used for indent tracking.
Defects:
* This patch does not handle the case where there's code between the `#ifndef` and `#define` but all other conditions hold. This is because when the #define line is parsed, `UnwrappedLineParser::Lines` doesn't hold the previous code line yet, so we can't detect it. This is out of the scope of this patch.
* This patch does not handle cases where legitimate lines may be outside an include guard. Examples are `#pragma once` and `#pragma GCC diagnostic`, or anything else that does not change the meaning of the file if it's included multiple times.
* This does not detect when there is a single non-preprocessor line in front of an include-guard-like structure where other conditions hold because `ScopedLineState` hides the line.
* Preprocessor indentation throws off `TokenAnnotator::setCommentLineLevels` so the indentation of comments immediately before indented preprocessor lines is toggled on each run. Fixing this issue appears to be a major change and too much complexity for this patch.
Contributed by @euhlmann!
Reviewers: djasper, klimek, krasimir
Reviewed By: djasper, krasimir
Subscribers: krasimir, mzeren-vmw, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D35955
llvm-svn: 312125
Summary: Style documentation is generated automatically by `docs/tools/dump_format_style.py`. This hasn't been ran for a while.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34457
llvm-svn: 306089
DontAlign
This converts the clang-format option AlignEscapedNewlinesLeft from a
boolean to an enum, named AlignEscapedNewlines, with options Left (prev.
true), Right (prev. false), and a new option DontAlign.
When set to DontAlign, the backslashes are placed just after the last token in each line:
#define EXAMPLE \
do { \
int x = aaaaa; \
int b; \
int dddddddddd; \
} while (0)
Patch by jtbandes. Thank you!
llvm-svn: 302428
clang-format <<END
auto c1 = u8'a';
auto c2 = u'a';
END
Before:
auto c1 = u8 'a';
auto c2 = u'a';
Now:
auto c1 = u8'a';
auto c2 = u'a';
Patch from Denis Gladkikh <llvm@denis.gladkikh.email>!
llvm-svn: 299574
Summary:
This patch enables namespace end comments under a new flag FixNamespaceComments,
which is enabled for the LLVM and Google styles.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30405
llvm-svn: 296632
Summary:
This is required for compliance with the Mozilla style guide.
This is a rebase+minor change of Birunthan Mohanathas's patch
Reviewers: djasper
Subscribers: klimek, cfe-commits, opilarium
Differential Revision: https://reviews.llvm.org/D23317
llvm-svn: 278121
This patch adds a regular expression to configure suffixes of an
included file to check whether it is the "main" include of the current
file. Previously, clang-format has allowed arbitrary suffixes on the
formatted file, which is still the case when no IncludeMainRegex is
specified.
llvm-svn: 263943
This changes the behavior of AlwaysBreakAfterDeclarationReturnType
so that it supports breaking after declarations, definitions, or
both.
Differential Revision: http://reviews.llvm.org/D10370
Reviewed By: Daniel Jasper
llvm-svn: 256046
Summary:
If this option is set, clang-format will always insert a line wrap, e.g.
before the first parameter of a function call unless all parameters fit
on the same line. This obviates the need to make a decision on the
alignment itself.
Use this style for Google's JavaScript style and add some minor tweaks
to correctly handle nested blocks etc. with it. Don't use this option
for for/while loops.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D14104
llvm-svn: 251405
This was made much easier by introducing an IncludeCategory struct to
replace the previously used std::pair.
Also, cleaned up documentation and added examples.
llvm-svn: 249392
statement. Specifically, we don't want people that have already written
a patch to just write a style guide for their 1-person project.
llvm-svn: 249290
control the individual braces. The existing choices for brace wrapping
are now merely presets for the different flags that get expanded upon
calling the reformat function.
All presets have been chose to keep the existing formatting, so there
shouldn't be any difference in formatting behavior.
Also change the dump_format_style.py to properly document the nested
structs that are used to keep these flags discoverable among all the
configuration flags.
llvm-svn: 248802
Summary:
Add brace style `BS_WebKit` as described on https://www.webkit.org/coding/coding-style.html:
* Function definitions: place each brace on its own line.
* Other braces: place the open brace on the line preceding the code block; place the close brace on its own line.
Set brace style used in `getWebKitStyle()` to the newly added `BS_WebKit`.
Reviewers: djasper, klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D11837
llvm-svn: 244446
The MacroBlockBegin and MacroBlockEnd options make matching macro identifiers
behave like '{' and '}', respectively, in terms of indentation.
Mozilla code, for example, uses several macros that begin and end a scope.
Previously, Clang-Format removed the indentation resulting in:
MACRO_BEGIN(...)
MACRO_ENTRY(...)
MACRO_ENTRY(...)
MACRO_END
Now, using the options
MacroBlockBegin: "^[A-Z_]+_BEGIN$"
MacroBlockEnd: "^[A-Z_]+_END$"
will yield the expected result:
MACRO_BEGIN(...)
MACRO_ENTRY(...)
MACRO_ENTRY(...)
MACRO_END
Differential Revision: http://reviews.llvm.org/D10840
llvm-svn: 241363
In essence this is meant to consistently indent multiline strings by a
fixed amount of spaces from the start of the line. Don't do this in
cases where it wouldn't help anyway.
Before:
someFunction(aaaaa,
"aaaaa"
"bbbbb");
After:
someFunction(aaaaa, "aaaaa"
"bbbbb");
llvm-svn: 240004
In the long run, these two might be independent or we might to only
allow specific combinations. Until we have a corresponding request,
however, it is hard to do the right thing and choose the right
configuration options. Thus, just don't touch the options yet and
just modify the behavior slightly.
llvm-svn: 239531
In Objective-C some style guides use a style where assignment operators are
aligned, in an effort to increase code readability. This patch adds an option
to the format library which allows this functionality. It is disabled by
default for all the included styles, so it must be explicitly enabled.
The option will change code such as:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
to:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
Patch by Matt Oakes. Thank you!
Accidentally reformatted all the tests...
llvm-svn: 236100
With alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
Without alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
This fixes llvm.org/PR21666.
llvm-svn: 223117
On a single line:
switch (a) {
case 1: x = 1; return;
case 2: x = 2; return;
default: break;
}
Not on a single line:
switch (a) {
case 1:
x = 1;
return;
case 2:
x = 2;
return;
default:
break;
}
This partly addresses llvm.org/PR16535. In the long run, we probably want to
lay these out in columns.
llvm-svn: 217501
This permits to add a space after closing parenthesis of a C-style cast.
Defaults to false to preserve old behavior.
Fixes llvm.org/PR19982.
Before:
(int)i;
After:
(int) i;
Patch by Marek Kurdej.
llvm-svn: 217022
This is required for GNU coding style, among others.
Also update the configuration documentation.
Modified from an original patch by Jarkko Hietaniemi, thank you!
llvm-svn: 214858
Though not completely identical, make former
IndentFunctionDeclarationAfterType change this flag for backwards
compatibility (it is somewhat close in meaning and better the err'ing on
an unknown config flag).
llvm-svn: 212597
Summary:
The rule from the GNU style states:
"We find it easier to read a program when it has spaces before the open-parentheses and after the commas."
http://www.gnu.org/prep/standards/standards.html#index-spaces-before-open_002dparen
This patch makes clang-format adds an option to put spaces before almost all open parentheses, except the cases, where different behavior is dictated by the style rules or language syntax:
* preprocessor:
** function-like macro definitions can't have a space between the macro name and the parenthesis;
** `#if defined(...)` can have a space, but it seems, that it's more frequently used without a space in GCC, for example;
* never add spaces after unary operators;
* adding spaces between two opening parentheses is controlled with the `SpacesInParentheses` option;
* never add spaces between `[` and `(` (there's no option yet).
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2326
llvm-svn: 196901
Dotfiles are impractical on Windows. This makes clang-format search
for the style configuration file as '_clang-format' in addition to
the usual '.clang-format'. This is similar to how VIM searches for
'_vimrc' on Windows.
Differential Revision: http://llvm-reviews.chandlerc.com/D1629
llvm-svn: 190413
Summary:
The main contents is in the ClangFormatStyleOptions.rst, which can be
updated from the Format.h by the dump_format_style.py script.
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1597
llvm-svn: 189946
Sam McCall