2013-09-04 23:09:13 +08:00
|
|
|
==========================
|
|
|
|
Clang-Format Style Options
|
|
|
|
==========================
|
|
|
|
|
|
|
|
:doc:`ClangFormatStyleOptions` describes configurable formatting style options
|
|
|
|
supported by :doc:`LibFormat` and :doc:`ClangFormat`.
|
|
|
|
|
|
|
|
When using :program:`clang-format` command line utility or
|
|
|
|
``clang::format::reformat(...)`` functions from code, one can either use one of
|
[clang-format] Add basic support for formatting C# files
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
2019-03-21 21:09:22 +08:00
|
|
|
the predefined styles (LLVM, Google, Chromium, Mozilla, WebKit, Microsoft) or
|
|
|
|
create a custom style by configuring specific style options.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
Configuring Style with clang-format
|
|
|
|
===================================
|
|
|
|
|
|
|
|
:program:`clang-format` supports two ways to provide custom style options:
|
|
|
|
directly specify style configuration in the ``-style=`` command line option or
|
2013-09-10 23:41:12 +08:00
|
|
|
use ``-style=file`` and put style configuration in the ``.clang-format`` or
|
|
|
|
``_clang-format`` file in the project directory.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
|
|
|
When using ``-style=file``, :program:`clang-format` for each input file will
|
|
|
|
try to find the ``.clang-format`` file located in the closest parent directory
|
|
|
|
of the input file. When the standard input is used, the search is started from
|
|
|
|
the current directory.
|
|
|
|
|
|
|
|
The ``.clang-format`` file uses YAML format:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
key1: value1
|
|
|
|
key2: value2
|
|
|
|
# A comment.
|
|
|
|
...
|
|
|
|
|
2014-08-12 21:34:22 +08:00
|
|
|
The configuration file can consist of several sections each having different
|
|
|
|
``Language:`` parameter denoting the programming language this section of the
|
|
|
|
configuration is targeted at. See the description of the **Language** option
|
|
|
|
below for the list of supported languages. The first section may have no
|
|
|
|
language set, it will set the default style options for all lanugages.
|
|
|
|
Configuration sections for specific language will override options set in the
|
|
|
|
default section.
|
|
|
|
|
|
|
|
When :program:`clang-format` formats a file, it auto-detects the language using
|
|
|
|
the file name. When formatting standard input or a file that doesn't have the
|
|
|
|
extension corresponding to its language, ``-assume-filename=`` option can be
|
|
|
|
used to override the file name :program:`clang-format` uses to detect the
|
|
|
|
language.
|
|
|
|
|
|
|
|
An example of a configuration file for multiple languages:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
---
|
|
|
|
# We'll use defaults from the LLVM style, but with 4 columns indentation.
|
|
|
|
BasedOnStyle: LLVM
|
|
|
|
IndentWidth: 4
|
|
|
|
---
|
|
|
|
Language: Cpp
|
|
|
|
# Force pointers to the type for C++.
|
|
|
|
DerivePointerAlignment: false
|
|
|
|
PointerAlignment: Left
|
|
|
|
---
|
|
|
|
Language: JavaScript
|
|
|
|
# Use 100 columns for JS.
|
|
|
|
ColumnLimit: 100
|
|
|
|
---
|
|
|
|
Language: Proto
|
|
|
|
# Don't format .proto files.
|
|
|
|
DisableFormat: true
|
[clang-format] Add basic support for formatting C# files
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
2019-03-21 21:09:22 +08:00
|
|
|
---
|
|
|
|
Language: CSharp
|
|
|
|
# Use 100 columns for C#.
|
|
|
|
ColumnLimit: 100
|
2014-08-12 21:34:22 +08:00
|
|
|
...
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
An easy way to get a valid ``.clang-format`` file containing all configuration
|
|
|
|
options of a certain predefined style is:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
clang-format -style=llvm -dump-config > .clang-format
|
|
|
|
|
|
|
|
When specifying configuration in the ``-style=`` option, the same configuration
|
|
|
|
is applied for all input files. The format of the configuration is:
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
-style='{key1: value1, key2: value2, ...}'
|
|
|
|
|
|
|
|
|
2014-10-07 20:15:15 +08:00
|
|
|
Disabling Formatting on a Piece of Code
|
|
|
|
=======================================
|
|
|
|
|
|
|
|
Clang-format understands also special comments that switch formatting in a
|
|
|
|
delimited range. The code between a comment ``// clang-format off`` or
|
|
|
|
``/* clang-format off */`` up to a comment ``// clang-format on`` or
|
|
|
|
``/* clang-format on */`` will not be formatted. The comments themselves
|
|
|
|
will be formatted (aligned) normally.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
int formatted_code;
|
|
|
|
// clang-format off
|
|
|
|
void unformatted_code ;
|
|
|
|
// clang-format on
|
|
|
|
void formatted_code_again;
|
|
|
|
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
Configuring Style in Code
|
|
|
|
=========================
|
|
|
|
|
|
|
|
When using ``clang::format::reformat(...)`` functions, the format is specified
|
|
|
|
by supplying the `clang::format::FormatStyle
|
2018-11-05 01:02:00 +08:00
|
|
|
<https://clang.llvm.org/doxygen/structclang_1_1format_1_1FormatStyle.html>`_
|
2013-09-04 23:09:13 +08:00
|
|
|
structure.
|
|
|
|
|
|
|
|
|
|
|
|
Configurable Format Style Options
|
|
|
|
=================================
|
|
|
|
|
|
|
|
This section lists the supported style options. Value type is specified for
|
|
|
|
each option. For enumeration types possible values are specified both as a C++
|
2013-09-04 23:14:18 +08:00
|
|
|
enumeration member (with a prefix, e.g. ``LS_Auto``), and as a value usable in
|
|
|
|
the configuration (without a prefix: ``Auto``).
|
2013-09-04 23:09:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
**BasedOnStyle** (``string``)
|
|
|
|
The style used for all options not specifically set in the configuration.
|
|
|
|
|
|
|
|
This option is supported only in the :program:`clang-format` configuration
|
|
|
|
(both within ``-style='{...}'`` and the ``.clang-format`` file).
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``LLVM``
|
|
|
|
A style complying with the `LLVM coding standards
|
2018-11-05 01:02:00 +08:00
|
|
|
<https://llvm.org/docs/CodingStandards.html>`_
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``Google``
|
|
|
|
A style complying with `Google's C++ style guide
|
2019-07-29 19:00:23 +08:00
|
|
|
<https://google.github.io/styleguide/cppguide.html>`_
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``Chromium``
|
|
|
|
A style complying with `Chromium's style guide
|
2019-10-06 17:37:58 +08:00
|
|
|
<https://chromium.googlesource.com/chromium/src/+/master/styleguide/styleguide.md>`_
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``Mozilla``
|
|
|
|
A style complying with `Mozilla's style guide
|
|
|
|
<https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style>`_
|
|
|
|
* ``WebKit``
|
|
|
|
A style complying with `WebKit's style guide
|
2019-01-24 04:39:07 +08:00
|
|
|
<https://www.webkit.org/coding/coding-style.html>`_
|
[clang-format] Add basic support for formatting C# files
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
2019-03-21 21:09:22 +08:00
|
|
|
* ``Microsoft``
|
|
|
|
A style complying with `Microsoft's style guide
|
|
|
|
<https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference?view=vs-2017>`_
|
2020-05-21 00:17:55 +08:00
|
|
|
* ``GNU``
|
|
|
|
A style complying with the `GNU coding standards
|
|
|
|
<https://www.gnu.org/prep/standards/standards.html>`_
|
2013-09-04 23:09:13 +08:00
|
|
|
|
|
|
|
.. START_FORMAT_STYLE_OPTIONS
|
|
|
|
|
|
|
|
**AccessModifierOffset** (``int``)
|
2016-02-24 00:12:08 +08:00
|
|
|
The extra indent or outdent of access modifiers, e.g. ``public:``.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2015-10-27 20:38:37 +08:00
|
|
|
**AlignAfterOpenBracket** (``BracketAlignmentStyle``)
|
2014-12-02 21:24:51 +08:00
|
|
|
If ``true``, horizontally aligns arguments after an open bracket.
|
|
|
|
|
|
|
|
This applies to round brackets (parentheses), angle brackets and square
|
2016-02-24 00:11:51 +08:00
|
|
|
brackets.
|
2015-10-06 20:11:51 +08:00
|
|
|
|
2015-10-27 20:38:37 +08:00
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``BAS_Align`` (in configuration: ``Align``)
|
|
|
|
Align parameters on the open bracket, e.g.:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
someLongFunction(argument1,
|
|
|
|
argument2);
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2015-10-27 20:38:37 +08:00
|
|
|
* ``BAS_DontAlign`` (in configuration: ``DontAlign``)
|
|
|
|
Don't align, instead use ``ContinuationIndentWidth``, e.g.:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
someLongFunction(argument1,
|
|
|
|
argument2);
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2015-10-27 20:38:37 +08:00
|
|
|
* ``BAS_AlwaysBreak`` (in configuration: ``AlwaysBreak``)
|
|
|
|
Always break after an open bracket, if the parameters don't fit
|
|
|
|
on a single line, e.g.:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
someLongFunction(
|
|
|
|
argument1, argument2);
|
2015-10-07 21:02:45 +08:00
|
|
|
|
2014-12-02 21:24:51 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2015-04-29 21:06:49 +08:00
|
|
|
**AlignConsecutiveAssignments** (``bool``)
|
|
|
|
If ``true``, aligns consecutive assignments.
|
|
|
|
|
|
|
|
This will align the assignment operators of consecutive lines. This
|
|
|
|
will result in formattings like
|
2015-10-06 20:11:51 +08:00
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
.. code-block:: c++
|
2015-10-07 21:02:45 +08:00
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
int aaaa = 12;
|
|
|
|
int b = 23;
|
|
|
|
int ccc = 23;
|
|
|
|
|
2020-05-20 14:42:07 +08:00
|
|
|
**AlignConsecutiveBitFields** (``bool``)
|
|
|
|
If ``true``, aligns consecutive bitfield members.
|
|
|
|
|
|
|
|
This will align the bitfield separators of consecutive lines. This
|
|
|
|
will result in formattings like
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
int aaaa : 1;
|
|
|
|
int b : 12;
|
|
|
|
int ccc : 8;
|
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
**AlignConsecutiveDeclarations** (``bool``)
|
|
|
|
If ``true``, aligns consecutive declarations.
|
|
|
|
|
|
|
|
This will align the declaration names of consecutive lines. This
|
|
|
|
will result in formattings like
|
2015-10-06 20:11:51 +08:00
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
.. code-block:: c++
|
2015-10-07 21:02:45 +08:00
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
int aaaa = 12;
|
|
|
|
float b = 23;
|
|
|
|
std::string ccc = 23;
|
2015-04-29 21:06:49 +08:00
|
|
|
|
2019-08-10 15:51:21 +08:00
|
|
|
**AlignConsecutiveMacros** (``bool``)
|
|
|
|
If ``true``, aligns consecutive C/C++ preprocessor macros.
|
|
|
|
|
|
|
|
This will align C/C++ preprocessor macros of consecutive lines.
|
|
|
|
Will result in formattings like
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
#define SHORT_NAME 42
|
|
|
|
#define LONGER_NAME 0x007f
|
|
|
|
#define EVEN_LONGER_NAME (2)
|
|
|
|
#define foo(x) (x * x)
|
|
|
|
#define bar(y, z) (y + z)
|
|
|
|
|
2017-05-08 23:08:00 +08:00
|
|
|
**AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``)
|
|
|
|
Options for aligning backslashes in escaped newlines.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-05-08 23:08:00 +08:00
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``ENAS_DontAlign`` (in configuration: ``DontAlign``)
|
|
|
|
Don't align escaped newlines.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
#define A \
|
|
|
|
int aaaa; \
|
|
|
|
int b; \
|
|
|
|
int dddddddddd;
|
|
|
|
|
|
|
|
* ``ENAS_Left`` (in configuration: ``Left``)
|
|
|
|
Align escaped newlines as far left as possible.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
#define A \
|
|
|
|
int aaaa; \
|
|
|
|
int b; \
|
|
|
|
int dddddddddd;
|
|
|
|
|
|
|
|
false:
|
|
|
|
|
|
|
|
* ``ENAS_Right`` (in configuration: ``Right``)
|
|
|
|
Align escaped newlines in the right-most column.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
#define A \
|
|
|
|
int aaaa; \
|
|
|
|
int b; \
|
|
|
|
int dddddddddd;
|
2017-03-07 00:35:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
[clang-format] Fix AlignOperands when BreakBeforeBinaryOperators is set
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
2017-05-22 17:23:08 +08:00
|
|
|
**AlignOperands** (``OperandAlignmentStyle``)
|
2014-12-02 21:24:51 +08:00
|
|
|
If ``true``, horizontally align operands of binary and ternary
|
|
|
|
expressions.
|
|
|
|
|
[clang-format] Fix AlignOperands when BreakBeforeBinaryOperators is set
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
2017-05-22 17:23:08 +08:00
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``OAS_DontAlign`` (in configuration: ``DontAlign``)
|
|
|
|
Do not align operands of binary and ternary expressions.
|
|
|
|
The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
|
|
|
|
the start of the line.
|
|
|
|
|
|
|
|
* ``OAS_Align`` (in configuration: ``Align``)
|
|
|
|
Horizontally align operands of binary and ternary expressions.
|
|
|
|
|
|
|
|
Specifically, this aligns operands of a single expression that needs
|
|
|
|
to be split over multiple lines, e.g.:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
int aaa = bbbbbbbbbbbbbbb +
|
|
|
|
ccccccccccccccc;
|
|
|
|
|
|
|
|
When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
|
|
|
|
aligned with the operand on the first line.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
int aaa = bbbbbbbbbbbbbbb
|
|
|
|
+ ccccccccccccccc;
|
|
|
|
|
|
|
|
* ``OAS_AlignAfterOperator`` (in configuration: ``AlignAfterOperator``)
|
|
|
|
Horizontally align operands of binary and ternary expressions.
|
|
|
|
|
|
|
|
This is similar to ``AO_Align``, except when
|
|
|
|
``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
|
|
|
|
that the wrapped operand is aligned with the operand on the first line.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
int aaa = bbbbbbbbbbbbbbb
|
|
|
|
+ ccccccccccccccc;
|
2016-02-24 00:11:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**AlignTrailingComments** (``bool``)
|
|
|
|
If ``true``, aligns trailing comments.
|
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-11-09 23:41:23 +08:00
|
|
|
true: false:
|
|
|
|
int a; // My comment a vs. int a; // My comment a
|
|
|
|
int b = 2; // comment b int b = 2; // comment about b
|
2017-03-07 00:35:28 +08:00
|
|
|
|
Clang-format: add finer-grained options for putting all arguments on one line
Summary:
Add two new options,
AllowAllArgumentsOnNextLine and
AllowAllConstructorInitializersOnNextLine. These mirror the existing
AllowAllParametersOfDeclarationOnNextLine and allow me to support an
internal style guide where I work. I think this would be generally
useful, some have asked for it on stackoverflow:
https://stackoverflow.com/questions/30057534/clang-format-binpackarguments-not-working-as-expected
https://stackoverflow.com/questions/38635106/clang-format-how-to-prevent-all-function-arguments-on-next-line
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: jkorous, MyDeveloperDay, aol-nnov, lebedev.ri, uohcsemaj, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D40988
Patch By: russellmcc (Russell McClellan)
llvm-svn: 356834
2019-03-23 22:37:58 +08:00
|
|
|
**AllowAllArgumentsOnNextLine** (``bool``)
|
|
|
|
If a function call or braced initializer list doesn't fit on a
|
|
|
|
line, allow putting all arguments onto the next line, even if
|
|
|
|
``BinPackArguments`` is ``false``.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
callFunction(
|
|
|
|
a, b, c, d);
|
|
|
|
|
|
|
|
false:
|
|
|
|
callFunction(a,
|
|
|
|
b,
|
|
|
|
c,
|
|
|
|
d);
|
|
|
|
|
|
|
|
**AllowAllConstructorInitializersOnNextLine** (``bool``)
|
|
|
|
If a constructor definition with a member initializer list doesn't
|
|
|
|
fit on a single line, allow putting all member initializers onto the next
|
|
|
|
line, if ```ConstructorInitializerAllOnOneLineOrOnePerLine``` is true.
|
|
|
|
Note that this parameter has no effect if
|
|
|
|
```ConstructorInitializerAllOnOneLineOrOnePerLine``` is false.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
MyClass::MyClass() :
|
|
|
|
member0(0), member1(2) {}
|
|
|
|
|
|
|
|
false:
|
|
|
|
MyClass::MyClass() :
|
|
|
|
member0(0),
|
|
|
|
member1(2) {}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**AllowAllParametersOfDeclarationOnNextLine** (``bool``)
|
2017-09-07 21:45:41 +08:00
|
|
|
If the function declaration doesn't fit on a line,
|
|
|
|
allow putting all parameters of a function declaration onto
|
2013-09-04 23:09:13 +08:00
|
|
|
the next line even if ``BinPackParameters`` is ``false``.
|
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-09-07 21:45:41 +08:00
|
|
|
true:
|
|
|
|
void myFunction(
|
|
|
|
int a, int b, int c, int d, int e);
|
|
|
|
|
|
|
|
false:
|
|
|
|
void myFunction(int a,
|
|
|
|
int b,
|
|
|
|
int c,
|
|
|
|
int d,
|
|
|
|
int e);
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2019-08-12 01:48:36 +08:00
|
|
|
**AllowShortBlocksOnASingleLine** (``ShortBlockStyle``)
|
|
|
|
Dependent on the value, ``while (true) { continue; }`` can be put on a
|
|
|
|
single line.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``SBS_Never`` (in configuration: ``Never``)
|
|
|
|
Never merge blocks into a single line.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
while (true) {
|
|
|
|
}
|
|
|
|
while (true) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``SBS_Empty`` (in configuration: ``Empty``)
|
|
|
|
Only merge empty blocks.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
while (true) {}
|
|
|
|
while (true) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``SBS_Always`` (in configuration: ``Always``)
|
|
|
|
Always merge short blocks into a single line.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
while (true) {}
|
|
|
|
while (true) { continue; }
|
|
|
|
|
2014-05-14 17:33:35 +08:00
|
|
|
|
|
|
|
|
2014-09-10 21:11:45 +08:00
|
|
|
**AllowShortCaseLabelsOnASingleLine** (``bool``)
|
|
|
|
If ``true``, short case labels will be contracted to a single line.
|
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
switch (a) { vs. switch (a) {
|
|
|
|
case 1: x = 1; break; case 1:
|
|
|
|
case 2: return; x = 1;
|
|
|
|
} break;
|
|
|
|
case 2:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-05-01 00:11:54 +08:00
|
|
|
**AllowShortEnumsOnASingleLine** (``bool``)
|
|
|
|
Allow short enums on a single line.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
enum { A, B } myEnum;
|
|
|
|
|
|
|
|
false:
|
|
|
|
enum
|
|
|
|
{
|
|
|
|
A,
|
|
|
|
B
|
|
|
|
} myEnum;
|
|
|
|
|
2014-04-09 22:05:49 +08:00
|
|
|
**AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``)
|
2016-02-24 00:12:00 +08:00
|
|
|
Dependent on the value, ``int f() { return 0; }`` can be put on a
|
|
|
|
single line.
|
2014-04-09 22:05:49 +08:00
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``SFS_None`` (in configuration: ``None``)
|
|
|
|
Never merge functions into a single line.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-06-23 16:48:00 +08:00
|
|
|
* ``SFS_InlineOnly`` (in configuration: ``InlineOnly``)
|
|
|
|
Only merge functions defined inside a class. Same as "inline",
|
|
|
|
except it does not implies "empty": i.e. top level empty functions
|
|
|
|
are not merged either.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
class Foo {
|
|
|
|
void f() { foo(); }
|
|
|
|
};
|
|
|
|
void f() {
|
|
|
|
foo();
|
|
|
|
}
|
|
|
|
void f() {
|
|
|
|
}
|
|
|
|
|
2014-12-02 21:24:51 +08:00
|
|
|
* ``SFS_Empty`` (in configuration: ``Empty``)
|
|
|
|
Only merge empty functions.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-06-23 16:48:00 +08:00
|
|
|
void f() {}
|
2017-03-08 21:24:46 +08:00
|
|
|
void f2() {
|
|
|
|
bar2();
|
|
|
|
}
|
|
|
|
|
2015-06-11 21:31:45 +08:00
|
|
|
* ``SFS_Inline`` (in configuration: ``Inline``)
|
|
|
|
Only merge functions defined inside a class. Implies "empty".
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-03-21 01:07:49 +08:00
|
|
|
class Foo {
|
2017-03-08 21:24:46 +08:00
|
|
|
void f() { foo(); }
|
|
|
|
};
|
2017-06-23 16:48:00 +08:00
|
|
|
void f() {
|
|
|
|
foo();
|
|
|
|
}
|
|
|
|
void f() {}
|
2017-03-08 21:24:46 +08:00
|
|
|
|
2014-04-09 22:05:49 +08:00
|
|
|
* ``SFS_All`` (in configuration: ``All``)
|
|
|
|
Merge all functions fitting on a single line.
|
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-03-21 01:07:49 +08:00
|
|
|
class Foo {
|
2017-03-08 21:24:46 +08:00
|
|
|
void f() { foo(); }
|
|
|
|
};
|
|
|
|
void f() { bar(); }
|
|
|
|
|
2019-04-09 07:36:25 +08:00
|
|
|
|
|
|
|
|
2019-03-13 16:26:39 +08:00
|
|
|
**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``)
|
2019-04-09 07:36:25 +08:00
|
|
|
If ``true``, ``if (a) return;`` can be put on a single line.
|
2019-03-13 16:26:39 +08:00
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``SIS_Never`` (in configuration: ``Never``)
|
2019-04-09 07:36:25 +08:00
|
|
|
Never put short ifs on the same line.
|
2019-03-13 16:26:39 +08:00
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2019-04-09 07:36:25 +08:00
|
|
|
if (a)
|
|
|
|
return ;
|
|
|
|
else {
|
|
|
|
return;
|
|
|
|
}
|
2013-12-10 18:18:34 +08:00
|
|
|
|
2019-03-13 16:26:39 +08:00
|
|
|
* ``SIS_WithoutElse`` (in configuration: ``WithoutElse``)
|
2019-04-09 07:36:25 +08:00
|
|
|
Without else put short ifs on the same line only if
|
|
|
|
the else is not a compound statement.
|
2019-03-13 16:26:39 +08:00
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2019-04-09 07:36:25 +08:00
|
|
|
if (a) return;
|
|
|
|
else
|
|
|
|
return;
|
2019-03-13 16:26:39 +08:00
|
|
|
|
|
|
|
* ``SIS_Always`` (in configuration: ``Always``)
|
2019-04-09 07:36:25 +08:00
|
|
|
Always put short ifs on the same line if
|
|
|
|
the else is not a compound statement or not.
|
2019-03-13 16:26:39 +08:00
|
|
|
|
|
|
|
.. code-block:: c++
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2019-04-09 07:36:25 +08:00
|
|
|
if (a) return;
|
|
|
|
else {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2019-03-27 04:18:14 +08:00
|
|
|
**AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``)
|
|
|
|
Dependent on the value, ``auto lambda []() { return 0; }`` can be put on a
|
|
|
|
single line.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``SLS_None`` (in configuration: ``None``)
|
|
|
|
Never merge lambdas into a single line.
|
|
|
|
|
|
|
|
* ``SLS_Empty`` (in configuration: ``Empty``)
|
|
|
|
Only merge empty lambdas.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
auto lambda = [](int a) {}
|
|
|
|
auto lambda2 = [](int a) {
|
|
|
|
return a;
|
|
|
|
};
|
|
|
|
|
|
|
|
* ``SLS_Inline`` (in configuration: ``Inline``)
|
|
|
|
Merge lambda into a single line if argument of a function.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
auto lambda = [](int a) {
|
|
|
|
return a;
|
|
|
|
};
|
|
|
|
sort(a.begin(), a.end(), ()[] { return x < y; })
|
|
|
|
|
|
|
|
* ``SLS_All`` (in configuration: ``All``)
|
|
|
|
Merge all lambdas fitting on a single line.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
auto lambda = [](int a) {}
|
|
|
|
auto lambda2 = [](int a) { return a; };
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**AllowShortLoopsOnASingleLine** (``bool``)
|
2016-02-24 00:12:00 +08:00
|
|
|
If ``true``, ``while (true) continue;`` can be put on a single
|
|
|
|
line.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2015-06-29 23:30:42 +08:00
|
|
|
**AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``)
|
2015-12-19 06:20:15 +08:00
|
|
|
The function definition return type breaking style to use. This
|
2017-03-20 20:56:40 +08:00
|
|
|
option is **deprecated** and is retained for backwards compatibility.
|
2015-06-29 23:30:42 +08:00
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``DRTBS_None`` (in configuration: ``None``)
|
|
|
|
Break after return type automatically.
|
|
|
|
``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2015-06-29 23:30:42 +08:00
|
|
|
* ``DRTBS_All`` (in configuration: ``All``)
|
|
|
|
Always break after the return type.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2015-06-29 23:30:42 +08:00
|
|
|
* ``DRTBS_TopLevel`` (in configuration: ``TopLevel``)
|
2015-12-19 06:20:15 +08:00
|
|
|
Always break after the return types of top-level functions.
|
|
|
|
|
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2015-12-19 06:20:15 +08:00
|
|
|
**AlwaysBreakAfterReturnType** (``ReturnTypeBreakingStyle``)
|
|
|
|
The function declaration return type breaking style to use.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``RTBS_None`` (in configuration: ``None``)
|
|
|
|
Break after return type automatically.
|
|
|
|
``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
class A {
|
|
|
|
int f() { return 0; };
|
|
|
|
};
|
|
|
|
int f();
|
|
|
|
int f() { return 1; }
|
|
|
|
|
2015-12-19 06:20:15 +08:00
|
|
|
* ``RTBS_All`` (in configuration: ``All``)
|
|
|
|
Always break after the return type.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
class A {
|
|
|
|
int
|
|
|
|
f() {
|
|
|
|
return 0;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
int
|
|
|
|
f();
|
|
|
|
int
|
|
|
|
f() {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-12-19 06:20:15 +08:00
|
|
|
* ``RTBS_TopLevel`` (in configuration: ``TopLevel``)
|
|
|
|
Always break after the return types of top-level functions.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
class A {
|
|
|
|
int f() { return 0; };
|
|
|
|
};
|
|
|
|
int
|
|
|
|
f();
|
|
|
|
int
|
|
|
|
f() {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-12-19 06:20:15 +08:00
|
|
|
* ``RTBS_AllDefinitions`` (in configuration: ``AllDefinitions``)
|
|
|
|
Always break after the return type of function definitions.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
class A {
|
|
|
|
int
|
|
|
|
f() {
|
|
|
|
return 0;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
int f();
|
|
|
|
int
|
|
|
|
f() {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-12-19 06:20:15 +08:00
|
|
|
* ``RTBS_TopLevelDefinitions`` (in configuration: ``TopLevelDefinitions``)
|
|
|
|
Always break after the return type of top-level definitions.
|
2014-08-05 20:16:31 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
class A {
|
|
|
|
int f() { return 0; };
|
|
|
|
};
|
|
|
|
int f();
|
|
|
|
int
|
|
|
|
f() {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-08-05 20:16:31 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**AlwaysBreakBeforeMultilineStrings** (``bool``)
|
|
|
|
If ``true``, always break before multiline string literals.
|
|
|
|
|
2015-06-18 17:12:47 +08:00
|
|
|
This flag is mean to make cases where there are multiple multiline strings
|
|
|
|
in a file look more consistent. Thus, it will only take effect if wrapping
|
|
|
|
the string at that point leads to it being indented
|
|
|
|
``ContinuationIndentWidth`` spaces from the start of the line.
|
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
aaaa = vs. aaaa = "bbbb"
|
|
|
|
"bbbb" "cccc";
|
|
|
|
"cccc";
|
|
|
|
|
2018-05-16 16:25:03 +08:00
|
|
|
**AlwaysBreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``)
|
|
|
|
The template declaration breaking style to use.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``BTDS_No`` (in configuration: ``No``)
|
|
|
|
Do not force break before declaration.
|
|
|
|
``PenaltyBreakTemplateDeclaration`` is taken into account.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
template <typename T> T foo() {
|
|
|
|
}
|
|
|
|
template <typename T> T foo(int aaaaaaaaaaaaaaaaaaaaa,
|
|
|
|
int bbbbbbbbbbbbbbbbbbbbb) {
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``BTDS_MultiLine`` (in configuration: ``MultiLine``)
|
|
|
|
Force break after template declaration only when the following
|
|
|
|
declaration spans multiple lines.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
template <typename T> T foo() {
|
|
|
|
}
|
|
|
|
template <typename T>
|
|
|
|
T foo(int aaaaaaaaaaaaaaaaaaaaa,
|
|
|
|
int bbbbbbbbbbbbbbbbbbbbb) {
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``BTDS_Yes`` (in configuration: ``Yes``)
|
|
|
|
Always break after template declaration.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
T foo() {
|
|
|
|
}
|
|
|
|
template <typename T>
|
|
|
|
T foo(int aaaaaaaaaaaaaaaaaaaaa,
|
|
|
|
int bbbbbbbbbbbbbbbbbbbbb) {
|
|
|
|
}
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2020-09-16 20:45:45 +08:00
|
|
|
|
|
|
|
|
2020-09-07 16:26:05 +08:00
|
|
|
**AttributeMacros** (``std::vector<std::string>``)
|
|
|
|
A vector of strings that should be interpreted as attributes/qualifiers
|
|
|
|
instead of identifiers. This can be useful for language extensions or
|
2020-09-16 20:45:45 +08:00
|
|
|
static analyzer annotations.
|
|
|
|
|
|
|
|
For example:
|
2017-03-07 00:35:28 +08:00
|
|
|
|
2020-09-07 16:26:05 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
x = (char *__capability)&y;
|
|
|
|
int function(void) __ununsed;
|
|
|
|
void only_writes_to_buffer(char *__output buffer);
|
|
|
|
|
|
|
|
In the .clang-format configuration file, this can be configured like:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
AttributeMacros: ['__capability', '__output', '__ununsed']
|
|
|
|
|
2014-10-09 17:52:05 +08:00
|
|
|
**BinPackArguments** (``bool``)
|
|
|
|
If ``false``, a function call's arguments will either be all on the
|
|
|
|
same line or will have one line each.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
void f() {
|
|
|
|
f(aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa,
|
|
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
|
|
|
|
}
|
|
|
|
|
|
|
|
false:
|
|
|
|
void f() {
|
|
|
|
f(aaaaaaaaaaaaaaaaaaaa,
|
|
|
|
aaaaaaaaaaaaaaaaaaaa,
|
|
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
|
|
|
|
}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**BinPackParameters** (``bool``)
|
2014-10-09 17:52:05 +08:00
|
|
|
If ``false``, a function declaration's or function definition's
|
|
|
|
parameters will either all be on the same line or will have one line each.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
void f(int aaaaaaaaaaaaaaaaaaaa, int aaaaaaaaaaaaaaaaaaaa,
|
|
|
|
int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
|
|
|
|
|
|
|
|
false:
|
|
|
|
void f(int aaaaaaaaaaaaaaaaaaaa,
|
|
|
|
int aaaaaaaaaaaaaaaaaaaa,
|
|
|
|
int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
|
|
|
|
|
2020-07-18 18:35:01 +08:00
|
|
|
**BitFieldColonSpacing** (``BitFieldColonSpacingStyle``)
|
|
|
|
The BitFieldColonSpacingStyle to use for bitfields.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``BFCS_Both`` (in configuration: ``Both``)
|
|
|
|
Add one space on each side of the ``:``
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
unsigned bf : 2;
|
|
|
|
|
|
|
|
* ``BFCS_None`` (in configuration: ``None``)
|
|
|
|
Add no space around the ``:`` (except when needed for
|
|
|
|
``AlignConsecutiveBitFields``).
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
unsigned bf:2;
|
|
|
|
|
|
|
|
* ``BFCS_Before`` (in configuration: ``Before``)
|
|
|
|
Add space before the ``:`` only
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
unsigned bf :2;
|
|
|
|
|
|
|
|
* ``BFCS_After`` (in configuration: ``After``)
|
|
|
|
Add space after the ``:`` only (space may be added before if
|
|
|
|
needed for ``AlignConsecutiveBitFields``).
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
unsigned bf: 2;
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
**BraceWrapping** (``BraceWrappingFlags``)
|
|
|
|
Control of individual brace wrapping cases.
|
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
If ``BreakBeforeBraces`` is set to ``BS_Custom``, use this to specify how
|
|
|
|
each individual brace case should be handled. Otherwise, this is ignored.
|
2015-09-29 22:57:55 +08:00
|
|
|
|
2017-09-07 20:09:14 +08:00
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
# Example of usage:
|
|
|
|
BreakBeforeBraces: Custom
|
|
|
|
BraceWrapping:
|
|
|
|
AfterEnum: true
|
|
|
|
AfterStruct: false
|
|
|
|
SplitEmptyFunction: false
|
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
Nested configuration flags:
|
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2019-04-09 07:36:25 +08:00
|
|
|
* ``bool AfterCaseLabel`` Wrap case labels.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
false: true:
|
|
|
|
switch (foo) { vs. switch (foo) {
|
|
|
|
case 1: { case 1:
|
|
|
|
bar(); {
|
|
|
|
break; bar();
|
|
|
|
} break;
|
|
|
|
default: { }
|
|
|
|
plop(); default:
|
|
|
|
} {
|
|
|
|
} plop();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool AfterClass`` Wrap class definitions.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
true:
|
|
|
|
class foo {};
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
false:
|
|
|
|
class foo
|
|
|
|
{};
|
2017-06-15 11:38:08 +08:00
|
|
|
|
[clang-format] Add ability to wrap braces after multi-line control statements
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
2019-10-04 02:42:31 +08:00
|
|
|
* ``BraceWrappingAfterControlStatementStyle AfterControlStatement``
|
|
|
|
Wrap control statements (``if``/``for``/``while``/``switch``/..).
|
2017-03-13 22:42:47 +08:00
|
|
|
|
[clang-format] Add ability to wrap braces after multi-line control statements
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
2019-10-04 02:42:31 +08:00
|
|
|
Possible values:
|
2017-03-13 22:42:47 +08:00
|
|
|
|
[clang-format] Add ability to wrap braces after multi-line control statements
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
2019-10-04 02:42:31 +08:00
|
|
|
* ``BWACS_Never`` (in configuration: ``Never``)
|
|
|
|
Never wrap braces after a control statement.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
[clang-format] Add ability to wrap braces after multi-line control statements
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
2019-10-04 02:42:31 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
if (foo()) {
|
|
|
|
} else {
|
|
|
|
}
|
|
|
|
for (int i = 0; i < 10; ++i) {
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``BWACS_MultiLine`` (in configuration: ``MultiLine``)
|
|
|
|
Only wrap braces after a multi-line control statement.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
if (foo && bar &&
|
|
|
|
baz)
|
|
|
|
{
|
|
|
|
quux();
|
|
|
|
}
|
|
|
|
while (foo || bar) {
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``BWACS_Always`` (in configuration: ``Always``)
|
|
|
|
Always wrap braces after a control statement.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
if (foo())
|
|
|
|
{
|
|
|
|
} else
|
|
|
|
{}
|
|
|
|
for (int i = 0; i < 10; ++i)
|
|
|
|
{}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2019-11-08 22:34:07 +08:00
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool AfterEnum`` Wrap enum definitions.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
true:
|
|
|
|
enum X : int
|
|
|
|
{
|
|
|
|
B
|
|
|
|
};
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
false:
|
|
|
|
enum X : int { B };
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool AfterFunction`` Wrap function definitions.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
true:
|
|
|
|
void foo()
|
|
|
|
{
|
|
|
|
bar();
|
|
|
|
bar2();
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
false:
|
|
|
|
void foo() {
|
|
|
|
bar();
|
|
|
|
bar2();
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool AfterNamespace`` Wrap namespace definitions.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
true:
|
|
|
|
namespace
|
|
|
|
{
|
|
|
|
int foo();
|
|
|
|
int bar();
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
false:
|
|
|
|
namespace {
|
|
|
|
int foo();
|
|
|
|
int bar();
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2018-03-06 21:24:01 +08:00
|
|
|
* ``bool AfterObjCDeclaration`` Wrap ObjC definitions (interfaces, implementations...).
|
|
|
|
@autoreleasepool and @synchronized blocks are wrapped
|
|
|
|
according to `AfterControlStatement` flag.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool AfterStruct`` Wrap struct definitions.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
true:
|
|
|
|
struct foo
|
|
|
|
{
|
|
|
|
int x;
|
|
|
|
};
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
false:
|
|
|
|
struct foo {
|
|
|
|
int x;
|
|
|
|
};
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool AfterUnion`` Wrap union definitions.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
true:
|
|
|
|
union foo
|
|
|
|
{
|
|
|
|
int x;
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
false:
|
|
|
|
union foo {
|
|
|
|
int x;
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-09-15 19:23:50 +08:00
|
|
|
* ``bool AfterExternBlock`` Wrap extern blocks.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
extern "C"
|
|
|
|
{
|
|
|
|
int foo();
|
|
|
|
}
|
|
|
|
|
|
|
|
false:
|
|
|
|
extern "C" {
|
|
|
|
int foo();
|
|
|
|
}
|
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool BeforeCatch`` Wrap before ``catch``.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
true:
|
|
|
|
try {
|
|
|
|
foo();
|
|
|
|
}
|
|
|
|
catch () {
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
false:
|
|
|
|
try {
|
|
|
|
foo();
|
|
|
|
} catch () {
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool BeforeElse`` Wrap before ``else``.
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
true:
|
|
|
|
if (foo()) {
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
false:
|
|
|
|
if (foo()) {
|
|
|
|
} else {
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2020-02-14 03:25:34 +08:00
|
|
|
* ``bool BeforeLambdaBody`` Wrap lambda block.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
connect(
|
|
|
|
[]()
|
|
|
|
{
|
|
|
|
foo();
|
|
|
|
bar();
|
|
|
|
});
|
|
|
|
|
|
|
|
false:
|
|
|
|
connect([]() {
|
|
|
|
foo();
|
|
|
|
bar();
|
|
|
|
});
|
|
|
|
|
2020-05-20 14:48:45 +08:00
|
|
|
* ``bool BeforeWhile`` Wrap before ``while``.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
do {
|
|
|
|
foo();
|
|
|
|
}
|
|
|
|
while (1);
|
|
|
|
|
|
|
|
false:
|
|
|
|
do {
|
|
|
|
foo();
|
|
|
|
} while (1);
|
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``bool IndentBraces`` Indent the wrapped braces themselves.
|
|
|
|
|
2017-09-07 20:08:49 +08:00
|
|
|
* ``bool SplitEmptyFunction`` If ``false``, empty function body can be put on a single line.
|
2017-06-23 19:29:40 +08:00
|
|
|
This option is used only if the opening brace of the function has
|
|
|
|
already been wrapped, i.e. the `AfterFunction` brace wrapping mode is
|
|
|
|
set, and the function could/should not be put on a single line (as per
|
|
|
|
`AllowShortFunctionsOnASingleLine` and constructor formatting options).
|
2017-06-23 16:48:00 +08:00
|
|
|
|
2017-06-23 19:29:40 +08:00
|
|
|
.. code-block:: c++
|
2017-06-23 16:48:00 +08:00
|
|
|
|
2019-12-13 10:58:56 +08:00
|
|
|
int f() vs. int f()
|
2017-06-23 19:29:40 +08:00
|
|
|
{} {
|
|
|
|
}
|
2017-06-23 16:48:00 +08:00
|
|
|
|
2017-09-07 20:08:49 +08:00
|
|
|
* ``bool SplitEmptyRecord`` If ``false``, empty record (e.g. class, struct or union) body
|
|
|
|
can be put on a single line. This option is used only if the opening
|
|
|
|
brace of the record has already been wrapped, i.e. the `AfterClass`
|
|
|
|
(for classes) brace wrapping mode is set.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
class Foo vs. class Foo
|
|
|
|
{} {
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``bool SplitEmptyNamespace`` If ``false``, empty namespace body can be put on a single line.
|
|
|
|
This option is used only if the opening brace of the namespace has
|
|
|
|
already been wrapped, i.e. the `AfterNamespace` brace wrapping mode is
|
|
|
|
set.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
namespace Foo vs. namespace Foo
|
|
|
|
{} {
|
|
|
|
}
|
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
|
2015-10-27 20:38:37 +08:00
|
|
|
**BreakAfterJavaFieldAnnotations** (``bool``)
|
|
|
|
Break after each annotation on a field in Java files.
|
|
|
|
|
2017-04-11 15:07:05 +08:00
|
|
|
.. code-block:: java
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
@Partial vs. @Partial @Mock DataLoad loader;
|
|
|
|
@Mock
|
|
|
|
DataLoad loader;
|
|
|
|
|
2014-09-15 19:11:00 +08:00
|
|
|
**BreakBeforeBinaryOperators** (``BinaryOperatorStyle``)
|
|
|
|
The way to wrap binary operators.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``BOS_None`` (in configuration: ``None``)
|
|
|
|
Break after operators.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
LooooooooooongType loooooooooooooooooooooongVariable =
|
|
|
|
someLooooooooooooooooongFunction();
|
|
|
|
|
|
|
|
bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
|
|
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
|
|
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
|
|
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
|
|
|
|
ccccccccccccccccccccccccccccccccccccccccc;
|
|
|
|
|
2014-09-15 19:11:00 +08:00
|
|
|
* ``BOS_NonAssignment`` (in configuration: ``NonAssignment``)
|
|
|
|
Break before operators that aren't assignments.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
LooooooooooongType loooooooooooooooooooooongVariable =
|
|
|
|
someLooooooooooooooooongFunction();
|
|
|
|
|
|
|
|
bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
|
|
+ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
|
|
== aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
|
|
&& aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
|
|
> ccccccccccccccccccccccccccccccccccccccccc;
|
|
|
|
|
2014-09-15 19:11:00 +08:00
|
|
|
* ``BOS_All`` (in configuration: ``All``)
|
|
|
|
Break before operators.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
LooooooooooongType loooooooooooooooooooooongVariable
|
|
|
|
= someLooooooooooooooooongFunction();
|
|
|
|
|
|
|
|
bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
|
|
+ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
|
|
== aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
|
|
&& aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
|
|
> ccccccccccccccccccccccccccccccccccccccccc;
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**BreakBeforeBraces** (``BraceBreakingStyle``)
|
|
|
|
The brace breaking style to use.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``BS_Attach`` (in configuration: ``Attach``)
|
|
|
|
Always attach braces to surrounding context.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
try {
|
|
|
|
foo();
|
|
|
|
} catch () {
|
|
|
|
}
|
|
|
|
void foo() { bar(); }
|
|
|
|
class foo {};
|
|
|
|
if (foo()) {
|
|
|
|
} else {
|
|
|
|
}
|
|
|
|
enum X : int { A, B };
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``BS_Linux`` (in configuration: ``Linux``)
|
|
|
|
Like ``Attach``, but break before braces on function, namespace and
|
|
|
|
class definitions.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
try {
|
|
|
|
foo();
|
|
|
|
} catch () {
|
|
|
|
}
|
|
|
|
void foo() { bar(); }
|
|
|
|
class foo
|
|
|
|
{
|
|
|
|
};
|
|
|
|
if (foo()) {
|
|
|
|
} else {
|
|
|
|
}
|
|
|
|
enum X : int { A, B };
|
|
|
|
|
2015-07-12 11:13:54 +08:00
|
|
|
* ``BS_Mozilla`` (in configuration: ``Mozilla``)
|
|
|
|
Like ``Attach``, but break before braces on enum, function, and record
|
|
|
|
definitions.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
try {
|
|
|
|
foo();
|
|
|
|
} catch () {
|
|
|
|
}
|
|
|
|
void foo() { bar(); }
|
|
|
|
class foo
|
|
|
|
{
|
|
|
|
};
|
|
|
|
if (foo()) {
|
|
|
|
} else {
|
|
|
|
}
|
|
|
|
enum X : int { A, B };
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``BS_Stroustrup`` (in configuration: ``Stroustrup``)
|
2016-02-24 00:12:00 +08:00
|
|
|
Like ``Attach``, but break before function definitions, ``catch``, and
|
|
|
|
``else``.
|
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
try {
|
|
|
|
foo();
|
2018-10-26 15:25:37 +08:00
|
|
|
}
|
|
|
|
catch () {
|
2017-03-13 22:42:47 +08:00
|
|
|
}
|
|
|
|
void foo() { bar(); }
|
2018-10-26 15:25:37 +08:00
|
|
|
class foo {
|
2017-03-13 22:42:47 +08:00
|
|
|
};
|
|
|
|
if (foo()) {
|
|
|
|
}
|
2018-10-26 15:25:37 +08:00
|
|
|
else {
|
|
|
|
}
|
|
|
|
enum X : int { A, B };
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``BS_Allman`` (in configuration: ``Allman``)
|
|
|
|
Always break before braces.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2019-06-06 04:59:48 +08:00
|
|
|
try
|
|
|
|
{
|
2017-03-13 22:42:47 +08:00
|
|
|
foo();
|
|
|
|
}
|
2019-06-06 04:59:48 +08:00
|
|
|
catch ()
|
|
|
|
{
|
2017-03-13 22:42:47 +08:00
|
|
|
}
|
|
|
|
void foo() { bar(); }
|
2019-06-06 04:59:48 +08:00
|
|
|
class foo
|
|
|
|
{
|
2017-03-13 22:42:47 +08:00
|
|
|
};
|
2019-06-06 04:59:48 +08:00
|
|
|
if (foo())
|
|
|
|
{
|
2017-03-13 22:42:47 +08:00
|
|
|
}
|
2019-06-06 04:59:48 +08:00
|
|
|
else
|
|
|
|
{
|
2017-03-13 22:42:47 +08:00
|
|
|
}
|
2019-06-06 04:59:48 +08:00
|
|
|
enum X : int
|
|
|
|
{
|
|
|
|
A,
|
|
|
|
B
|
|
|
|
};
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2019-09-22 20:00:34 +08:00
|
|
|
* ``BS_Whitesmiths`` (in configuration: ``Whitesmiths``)
|
|
|
|
Like ``Allman`` but always indent braces and line up code with braces.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
foo();
|
|
|
|
}
|
|
|
|
catch ()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
void foo() { bar(); }
|
|
|
|
class foo
|
|
|
|
{
|
|
|
|
};
|
|
|
|
if (foo())
|
|
|
|
{
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
}
|
|
|
|
enum X : int
|
|
|
|
{
|
|
|
|
A,
|
|
|
|
B
|
|
|
|
};
|
|
|
|
|
2014-02-13 20:51:50 +08:00
|
|
|
* ``BS_GNU`` (in configuration: ``GNU``)
|
|
|
|
Always break before braces and add an extra level of indentation to
|
|
|
|
braces of control statements, not to those of class, function
|
|
|
|
or other definitions.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
foo();
|
|
|
|
}
|
|
|
|
catch ()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
void foo() { bar(); }
|
|
|
|
class foo
|
|
|
|
{
|
|
|
|
};
|
|
|
|
if (foo())
|
|
|
|
{
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
}
|
|
|
|
enum X : int
|
|
|
|
{
|
|
|
|
A,
|
|
|
|
B
|
|
|
|
};
|
|
|
|
|
2015-08-10 21:43:19 +08:00
|
|
|
* ``BS_WebKit`` (in configuration: ``WebKit``)
|
|
|
|
Like ``Attach``, but break before functions.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
try {
|
|
|
|
foo();
|
|
|
|
} catch () {
|
|
|
|
}
|
|
|
|
void foo() { bar(); }
|
|
|
|
class foo {
|
|
|
|
};
|
|
|
|
if (foo()) {
|
|
|
|
} else {
|
|
|
|
}
|
|
|
|
enum X : int { A, B };
|
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
* ``BS_Custom`` (in configuration: ``Custom``)
|
2016-02-24 00:12:00 +08:00
|
|
|
Configure each individual brace in `BraceWrapping`.
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
|
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
**BreakBeforeTernaryOperators** (``bool``)
|
|
|
|
If ``true``, ternary operators will be placed after line breaks.
|
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription
|
|
|
|
? firstValue
|
|
|
|
: SecondValueVeryVeryVeryVeryLong;
|
|
|
|
|
2017-06-06 15:26:19 +08:00
|
|
|
false:
|
2017-03-13 22:42:47 +08:00
|
|
|
veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription ?
|
|
|
|
firstValue :
|
|
|
|
SecondValueVeryVeryVeryVeryLong;
|
|
|
|
|
2017-06-23 16:48:00 +08:00
|
|
|
**BreakConstructorInitializers** (``BreakConstructorInitializersStyle``)
|
|
|
|
The constructor initializers style to use.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``BCIS_BeforeColon`` (in configuration: ``BeforeColon``)
|
|
|
|
Break constructor initializers before the colon and after the commas.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2018-06-14 21:32:14 +08:00
|
|
|
Constructor()
|
|
|
|
: initializer1(),
|
|
|
|
initializer2()
|
2017-06-23 16:48:00 +08:00
|
|
|
|
|
|
|
* ``BCIS_BeforeComma`` (in configuration: ``BeforeComma``)
|
|
|
|
Break constructor initializers before the colon and commas, and align
|
|
|
|
the commas with the colon.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2018-06-14 21:32:14 +08:00
|
|
|
Constructor()
|
|
|
|
: initializer1()
|
|
|
|
, initializer2()
|
2017-06-23 16:48:00 +08:00
|
|
|
|
|
|
|
* ``BCIS_AfterColon`` (in configuration: ``AfterColon``)
|
|
|
|
Break constructor initializers after the colon and commas.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2018-06-14 21:32:14 +08:00
|
|
|
Constructor() :
|
|
|
|
initializer1(),
|
|
|
|
initializer2()
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
|
|
|
|
|
2018-06-11 22:41:26 +08:00
|
|
|
**BreakInheritanceList** (``BreakInheritanceListStyle``)
|
|
|
|
The inheritance list style to use.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``BILS_BeforeColon`` (in configuration: ``BeforeColon``)
|
|
|
|
Break inheritance list before the colon and after the commas.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2018-06-14 21:32:14 +08:00
|
|
|
class Foo
|
|
|
|
: Base1,
|
|
|
|
Base2
|
|
|
|
{};
|
2018-06-11 22:41:26 +08:00
|
|
|
|
|
|
|
* ``BILS_BeforeComma`` (in configuration: ``BeforeComma``)
|
|
|
|
Break inheritance list before the colon and commas, and align
|
|
|
|
the commas with the colon.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2018-06-14 21:32:14 +08:00
|
|
|
class Foo
|
|
|
|
: Base1
|
|
|
|
, Base2
|
|
|
|
{};
|
2018-06-11 22:41:26 +08:00
|
|
|
|
|
|
|
* ``BILS_AfterColon`` (in configuration: ``AfterColon``)
|
|
|
|
Break inheritance list after the colon and commas.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2018-06-14 21:32:14 +08:00
|
|
|
class Foo :
|
|
|
|
Base1,
|
|
|
|
Base2
|
|
|
|
{};
|
2018-06-11 22:41:26 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-24 00:11:51 +08:00
|
|
|
**BreakStringLiterals** (``bool``)
|
|
|
|
Allow breaking string literals when formatting.
|
|
|
|
|
2019-10-25 04:08:57 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
const char* x = "veryVeryVeryVeryVeryVe"
|
|
|
|
"ryVeryVeryVeryVeryVery"
|
|
|
|
"VeryLongString";
|
|
|
|
|
|
|
|
false:
|
|
|
|
const char* x =
|
|
|
|
"veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**ColumnLimit** (``unsigned``)
|
|
|
|
The column limit.
|
|
|
|
|
|
|
|
A column limit of ``0`` means that there is no column limit. In this case,
|
|
|
|
clang-format will respect the input's line breaking decisions within
|
2013-12-10 18:18:34 +08:00
|
|
|
statements unless they contradict other rules.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2014-02-13 20:51:50 +08:00
|
|
|
**CommentPragmas** (``std::string``)
|
|
|
|
A regular expression that describes comments with special meaning,
|
|
|
|
which should not be split into lines or otherwise changed.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-03-21 01:07:49 +08:00
|
|
|
// CommentPragmas: '^ FOOBAR pragma:'
|
2017-03-20 20:56:40 +08:00
|
|
|
// Will leave the following line unaffected
|
|
|
|
#include <vector> // FOOBAR pragma: keep
|
|
|
|
|
2017-06-23 16:48:00 +08:00
|
|
|
**CompactNamespaces** (``bool``)
|
|
|
|
If ``true``, consecutive namespace declarations will be on the same
|
|
|
|
line. If ``false``, each namespace is declared on a new line.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
namespace Foo { namespace Bar {
|
|
|
|
}}
|
|
|
|
|
|
|
|
false:
|
|
|
|
namespace Foo {
|
|
|
|
namespace Bar {
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
If it does not fit on a single line, the overflowing namespaces get
|
|
|
|
wrapped:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
namespace Foo { namespace Bar {
|
|
|
|
namespace Extra {
|
|
|
|
}}}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**ConstructorInitializerAllOnOneLineOrOnePerLine** (``bool``)
|
|
|
|
If the constructor initializers don't fit on a line, put each
|
|
|
|
initializer on its own line.
|
|
|
|
|
2017-03-13 22:42:47 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
2018-10-23 02:48:58 +08:00
|
|
|
SomeClass::Constructor()
|
|
|
|
: aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa) {
|
|
|
|
return 0;
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
|
|
|
false:
|
2018-10-23 02:48:58 +08:00
|
|
|
SomeClass::Constructor()
|
|
|
|
: aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaa),
|
|
|
|
aaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa) {
|
|
|
|
return 0;
|
|
|
|
}
|
2017-03-13 22:42:47 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**ConstructorInitializerIndentWidth** (``unsigned``)
|
|
|
|
The number of characters to use for indentation of constructor
|
2018-06-11 22:41:26 +08:00
|
|
|
initializer lists as well as inheritance lists.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
**ContinuationIndentWidth** (``unsigned``)
|
|
|
|
Indent width for line continuations.
|
|
|
|
|
2017-04-11 15:07:05 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
ContinuationIndentWidth: 2
|
|
|
|
|
|
|
|
int i = // VeryVeryVeryVeryVeryLongComment
|
|
|
|
longFunction( // Again a long comment
|
|
|
|
arg);
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**Cpp11BracedListStyle** (``bool``)
|
|
|
|
If ``true``, format braced lists as best suited for C++11 braced
|
|
|
|
lists.
|
|
|
|
|
|
|
|
Important differences:
|
|
|
|
- No spaces inside the braced list.
|
|
|
|
- No line break before the closing brace.
|
|
|
|
- Indentation with the continuation indent, not with the block indent.
|
|
|
|
|
|
|
|
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. If there is no name,
|
|
|
|
a zero-length name is assumed.
|
|
|
|
|
2017-04-11 15:07:05 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
vector<int> x{1, 2, 3, 4}; vs. vector<int> x{ 1, 2, 3, 4 };
|
|
|
|
vector<T> x{{}, {}, {}, {}}; vector<T> x{ {}, {}, {}, {} };
|
|
|
|
f(MyMap[{composite, key}]); f(MyMap[{ composite, key }]);
|
|
|
|
new int[3]{1, 2, 3}; new int[3]{ 1, 2, 3 };
|
|
|
|
|
2019-11-16 19:54:21 +08:00
|
|
|
**DeriveLineEnding** (``bool``)
|
|
|
|
Analyze the formatted file for the most used line ending (``\r\n``
|
|
|
|
or ``\n``). ``UseCRLF`` is only used as a fallback if none can be derived.
|
|
|
|
|
2014-06-17 20:40:34 +08:00
|
|
|
**DerivePointerAlignment** (``bool``)
|
|
|
|
If ``true``, analyze the formatted file for the most common
|
2017-04-11 15:07:05 +08:00
|
|
|
alignment of ``&`` and ``*``.
|
|
|
|
Pointer and reference alignment styles are going to be updated according
|
|
|
|
to the preferences found in the file.
|
|
|
|
``PointerAlignment`` is then used only as fallback.
|
2014-06-17 20:40:34 +08:00
|
|
|
|
|
|
|
**DisableFormat** (``bool``)
|
2015-06-27 17:25:28 +08:00
|
|
|
Disables formatting completely.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
|
|
|
**ExperimentalAutoDetectBinPacking** (``bool``)
|
|
|
|
If ``true``, clang-format detects whether function calls and
|
|
|
|
definitions are formatted with one parameter per line.
|
|
|
|
|
|
|
|
Each call can be bin-packed, one-per-line or inconclusive. If it is
|
|
|
|
inconclusive, e.g. completely on one line, but a decision needs to be
|
|
|
|
made, clang-format analyzes whether there are other bin-packed cases in
|
|
|
|
the input file and act accordingly.
|
|
|
|
|
|
|
|
NOTE: This is an experimental flag, that might go away or be renamed. Do
|
|
|
|
not use this in config files, etc. Use at your own risk.
|
|
|
|
|
2017-03-01 23:35:39 +08:00
|
|
|
**FixNamespaceComments** (``bool``)
|
|
|
|
If ``true``, clang-format adds missing namespace end comments and
|
|
|
|
fixes invalid existing ones.
|
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
namespace a { vs. namespace a {
|
|
|
|
foo(); foo();
|
2019-04-26 15:05:47 +08:00
|
|
|
} // namespace a }
|
2017-03-07 00:35:28 +08:00
|
|
|
|
2014-04-01 20:55:11 +08:00
|
|
|
**ForEachMacros** (``std::vector<std::string>``)
|
2014-04-09 22:05:49 +08:00
|
|
|
A vector of macros that should be interpreted as foreach loops
|
|
|
|
instead of as function calls.
|
|
|
|
|
|
|
|
These are expected to be macros of the form:
|
2015-10-06 20:11:51 +08:00
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
.. code-block:: c++
|
2015-10-07 21:02:45 +08:00
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
FOREACH(<variable-declaration>, ...)
|
|
|
|
<loop-body>
|
|
|
|
|
|
|
|
In the .clang-format configuration file, this can be configured like:
|
2015-10-06 20:11:51 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
.. code-block:: yaml
|
2015-10-07 21:02:45 +08:00
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
ForEachMacros: ['RANGES_FOR', 'FOREACH']
|
2014-04-01 20:55:11 +08:00
|
|
|
|
2014-04-09 22:05:49 +08:00
|
|
|
For example: BOOST_FOREACH.
|
2014-04-01 20:55:11 +08:00
|
|
|
|
2017-11-27 21:23:45 +08:00
|
|
|
**IncludeBlocks** (``IncludeBlocksStyle``)
|
|
|
|
Dependent on the value, multiple ``#include`` blocks can be sorted
|
|
|
|
as one and divided based on category.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``IBS_Preserve`` (in configuration: ``Preserve``)
|
|
|
|
Sort each ``#include`` block separately.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
#include "b.h" into #include "b.h"
|
|
|
|
|
|
|
|
#include <lib/main.h> #include "a.h"
|
|
|
|
#include "a.h" #include <lib/main.h>
|
|
|
|
|
|
|
|
* ``IBS_Merge`` (in configuration: ``Merge``)
|
|
|
|
Merge multiple ``#include`` blocks together and sort as one.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
#include "b.h" into #include "a.h"
|
|
|
|
#include "b.h"
|
|
|
|
#include <lib/main.h> #include <lib/main.h>
|
|
|
|
#include "a.h"
|
|
|
|
|
|
|
|
* ``IBS_Regroup`` (in configuration: ``Regroup``)
|
|
|
|
Merge multiple ``#include`` blocks together and sort as one.
|
2018-01-18 00:17:26 +08:00
|
|
|
Then split into groups based on category priority. See
|
|
|
|
``IncludeCategories``.
|
2017-11-27 21:23:45 +08:00
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
#include "b.h" into #include "a.h"
|
|
|
|
#include "b.h"
|
|
|
|
#include <lib/main.h>
|
|
|
|
#include "a.h" #include <lib/main.h>
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
**IncludeCategories** (``std::vector<IncludeCategory>``)
|
2016-02-24 00:12:00 +08:00
|
|
|
Regular expressions denoting the different ``#include`` categories
|
|
|
|
used for ordering ``#includes``.
|
2015-09-29 22:57:55 +08:00
|
|
|
|
2018-07-25 18:21:47 +08:00
|
|
|
`POSIX extended
|
2019-01-24 04:39:07 +08:00
|
|
|
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html>`_
|
2018-07-25 18:21:47 +08:00
|
|
|
regular expressions are supported.
|
|
|
|
|
2015-09-29 22:57:55 +08:00
|
|
|
These regular expressions are matched against the filename of an include
|
|
|
|
(including the <> or "") in order. The value belonging to the first
|
2016-02-24 00:12:00 +08:00
|
|
|
matching regular expression is assigned and ``#includes`` are sorted first
|
2015-09-29 22:57:55 +08:00
|
|
|
according to increasing category number and then alphabetically within
|
|
|
|
each category.
|
|
|
|
|
2016-02-24 00:11:51 +08:00
|
|
|
If none of the regular expressions match, INT_MAX is assigned as
|
|
|
|
category. The main header for a source file automatically gets category 0.
|
2016-02-24 00:12:00 +08:00
|
|
|
so that it is generally kept at the beginning of the ``#includes``
|
2018-11-05 01:02:00 +08:00
|
|
|
(https://llvm.org/docs/CodingStandards.html#include-style). However, you
|
2016-02-24 00:11:51 +08:00
|
|
|
can also assign negative priorities if you have certain headers that
|
|
|
|
always need to be first.
|
2015-09-29 22:57:55 +08:00
|
|
|
|
2019-09-26 04:33:01 +08:00
|
|
|
There is a third and optional field ``SortPriority`` which can used while
|
|
|
|
``IncludeBloks = IBS_Regroup`` to define the priority in which ``#includes``
|
|
|
|
should be ordered, and value of ``Priority`` defines the order of
|
|
|
|
``#include blocks`` and also enables to group ``#includes`` of different
|
|
|
|
priority for order.``SortPriority`` is set to the value of ``Priority``
|
|
|
|
as default if it is not assigned.
|
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
To configure this in the .clang-format file, use:
|
2015-10-06 20:11:51 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
.. code-block:: yaml
|
2015-10-07 21:02:45 +08:00
|
|
|
|
2015-10-06 19:54:18 +08:00
|
|
|
IncludeCategories:
|
|
|
|
- Regex: '^"(llvm|llvm-c|clang|clang-c)/'
|
|
|
|
Priority: 2
|
2019-09-26 04:33:01 +08:00
|
|
|
SortPriority: 2
|
2017-09-07 20:08:49 +08:00
|
|
|
- Regex: '^(<|"(gtest|gmock|isl|json)/)'
|
2015-10-06 19:54:18 +08:00
|
|
|
Priority: 3
|
2018-07-25 18:21:47 +08:00
|
|
|
- Regex: '<[[:alnum:].]+>'
|
|
|
|
Priority: 4
|
2017-03-09 14:41:08 +08:00
|
|
|
- Regex: '.*'
|
2015-10-06 19:54:18 +08:00
|
|
|
Priority: 1
|
2019-09-26 04:33:01 +08:00
|
|
|
SortPriority: 0
|
2015-10-06 19:54:18 +08:00
|
|
|
|
2016-03-21 22:11:27 +08:00
|
|
|
**IncludeIsMainRegex** (``std::string``)
|
|
|
|
Specify a regular expression of suffixes that are allowed in the
|
|
|
|
file-to-main-include mapping.
|
|
|
|
|
|
|
|
When guessing whether a #include is the "main" include (to assign
|
|
|
|
category 0, see above), use this regex of allowed suffixes to the header
|
|
|
|
stem. A partial match is done, so that:
|
|
|
|
- "" means "arbitrary suffix"
|
|
|
|
- "$" means "no suffix"
|
|
|
|
|
|
|
|
For example, if configured to "(_test)?$", then a header a.h would be seen
|
|
|
|
as the "main" include in both a.cc and a_test.cc.
|
|
|
|
|
2019-11-13 05:15:17 +08:00
|
|
|
**IncludeIsMainSourceRegex** (``std::string``)
|
|
|
|
Specify a regular expression for files being formatted
|
|
|
|
that are allowed to be considered "main" in the
|
|
|
|
file-to-main-include mapping.
|
|
|
|
|
|
|
|
By default, clang-format considers files as "main" only when they end
|
|
|
|
with: ``.c``, ``.cc``, ``.cpp``, ``.c++``, ``.cxx``, ``.m`` or ``.mm``
|
|
|
|
extensions.
|
|
|
|
For these files a guessing of "main" include takes place
|
|
|
|
(to assign category 0, see above). This config option allows for
|
|
|
|
additional suffixes and extensions for files to be considered as "main".
|
|
|
|
|
|
|
|
For example, if this option is configured to ``(Impl\.hpp)$``,
|
|
|
|
then a file ``ClassImpl.hpp`` is considered "main" (in addition to
|
|
|
|
``Class.c``, ``Class.cc``, ``Class.cpp`` and so on) and "main
|
|
|
|
include file" logic will be executed (with *IncludeIsMainRegex* setting
|
|
|
|
also being respected in later phase). Without this option set,
|
|
|
|
``ClassImpl.hpp`` would not have the main include file put on top
|
|
|
|
before any other include.
|
|
|
|
|
2020-01-19 23:52:26 +08:00
|
|
|
**IndentCaseBlocks** (``bool``)
|
|
|
|
Indent case label blocks one level from the case label.
|
|
|
|
|
|
|
|
When ``false``, the block following the case label uses the same
|
|
|
|
indentation level as for the case label, treating the case label the same
|
|
|
|
as an if-statement.
|
|
|
|
When ``true``, the block gets indented as a scope block.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
false: true:
|
|
|
|
switch (fool) { vs. switch (fool) {
|
|
|
|
case 1: { case 1:
|
|
|
|
bar(); {
|
|
|
|
} break; bar();
|
|
|
|
default: { }
|
|
|
|
plop(); break;
|
|
|
|
} default:
|
|
|
|
} {
|
|
|
|
plop();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**IndentCaseLabels** (``bool``)
|
|
|
|
Indent case labels one level from the switch statement.
|
|
|
|
|
2019-11-09 05:12:22 +08:00
|
|
|
When ``false``, use the same indentation level as for the switch
|
|
|
|
statement. Switch statement body is always indented one level more than
|
2020-01-19 23:52:26 +08:00
|
|
|
case labels (except the first block following the case label, which
|
|
|
|
itself indents the code - unless IndentCaseBlocks is enabled).
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-04-11 15:07:05 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
false: true:
|
|
|
|
switch (fool) { vs. switch (fool) {
|
|
|
|
case 1: case 1:
|
|
|
|
bar(); bar();
|
|
|
|
break; break;
|
|
|
|
default: default:
|
|
|
|
plop(); plop();
|
|
|
|
} }
|
|
|
|
|
2020-05-21 04:25:18 +08:00
|
|
|
**IndentExternBlock** (``IndentExternBlockStyle``)
|
|
|
|
IndentExternBlockStyle is the type of indenting of extern blocks.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``IEBS_AfterExternBlock`` (in configuration: ``AfterExternBlock``)
|
|
|
|
Backwards compatible with AfterExternBlock's indenting.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
IndentExternBlock: AfterExternBlock
|
|
|
|
BraceWrapping.AfterExternBlock: true
|
|
|
|
extern "C"
|
|
|
|
{
|
|
|
|
void foo();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
IndentExternBlock: AfterExternBlock
|
|
|
|
BraceWrapping.AfterExternBlock: false
|
|
|
|
extern "C" {
|
|
|
|
void foo();
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``IEBS_NoIndent`` (in configuration: ``NoIndent``)
|
|
|
|
Does not indent extern blocks.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
extern "C" {
|
|
|
|
void foo();
|
|
|
|
}
|
|
|
|
|
|
|
|
* ``IEBS_Indent`` (in configuration: ``Indent``)
|
|
|
|
Indents extern blocks.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
extern "C" {
|
|
|
|
void foo();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-12 18:07:14 +08:00
|
|
|
**IndentGotoLabels** (``bool``)
|
|
|
|
Indent goto labels.
|
|
|
|
|
|
|
|
When ``false``, goto labels are flushed left.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
int f() { vs. int f() {
|
|
|
|
if (foo()) { if (foo()) {
|
|
|
|
label1: label1:
|
|
|
|
bar(); bar();
|
|
|
|
} }
|
|
|
|
label2: label2:
|
|
|
|
return 1; return 1;
|
|
|
|
} }
|
|
|
|
|
clang-format: Add preprocessor directive indentation
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
2017-08-30 22:34:57 +08:00
|
|
|
**IndentPPDirectives** (``PPDirectiveIndentStyle``)
|
2017-09-07 20:08:49 +08:00
|
|
|
The preprocessor directive indenting style to use.
|
clang-format: Add preprocessor directive indentation
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
2017-08-30 22:34:57 +08:00
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``PPDIS_None`` (in configuration: ``None``)
|
|
|
|
Does not indent any directives.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-09-07 20:08:49 +08:00
|
|
|
#if FOO
|
|
|
|
#if BAR
|
|
|
|
#include <foo>
|
|
|
|
#endif
|
|
|
|
#endif
|
clang-format: Add preprocessor directive indentation
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
2017-08-30 22:34:57 +08:00
|
|
|
|
|
|
|
* ``PPDIS_AfterHash`` (in configuration: ``AfterHash``)
|
|
|
|
Indents directives after the hash.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-09-07 20:08:49 +08:00
|
|
|
#if FOO
|
|
|
|
# if BAR
|
|
|
|
# include <foo>
|
|
|
|
# endif
|
|
|
|
#endif
|
|
|
|
|
[clang-format] BeforeHash added to IndentPPDirectives
Summary:
The option BeforeHash added to IndentPPDirectives.
Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019
Reviewers: djasper, klimek, krasimir, sammccall, mprobst, Nicola, MyDeveloperDay
Reviewed By: klimek, MyDeveloperDay
Subscribers: kadircet, MyDeveloperDay, mnussbaum, geleji, ufna, cfe-commits
Patch by to-mix.
Differential Revision: https://reviews.llvm.org/D52150
llvm-svn: 356613
2019-03-21 04:49:43 +08:00
|
|
|
* ``PPDIS_BeforeHash`` (in configuration: ``BeforeHash``)
|
|
|
|
Indents directives before the hash.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
#if FOO
|
|
|
|
#if BAR
|
|
|
|
#include <foo>
|
|
|
|
#endif
|
|
|
|
#endif
|
2017-09-07 20:08:49 +08:00
|
|
|
|
clang-format: Add preprocessor directive indentation
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
2017-08-30 22:34:57 +08:00
|
|
|
|
2019-04-09 07:36:25 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**IndentWidth** (``unsigned``)
|
2013-09-28 00:16:55 +08:00
|
|
|
The number of columns to use for indentation.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
IndentWidth: 3
|
2017-04-11 15:07:05 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
void f() {
|
|
|
|
someFunction();
|
|
|
|
if (true, false) {
|
|
|
|
f();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-09 16:42:42 +08:00
|
|
|
**IndentWrappedFunctionNames** (``bool``)
|
|
|
|
Indent if a function definition or declaration is wrapped after the
|
|
|
|
type.
|
|
|
|
|
2017-04-11 15:07:05 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true:
|
|
|
|
LoooooooooooooooooooooooooooooooooooooooongReturnType
|
|
|
|
LoooooooooooooooooooooooooooooooongFunctionDeclaration();
|
|
|
|
|
|
|
|
false:
|
|
|
|
LoooooooooooooooooooooooooooooooooooooooongReturnType
|
|
|
|
LoooooooooooooooooooooooooooooooongFunctionDeclaration();
|
|
|
|
|
2020-04-30 17:47:23 +08:00
|
|
|
**InsertTrailingCommas** (``TrailingCommaStyle``)
|
|
|
|
If set to ``TCS_Wrapped`` will insert trailing commas in container
|
|
|
|
literals (arrays and objects) that wrap across multiple lines.
|
|
|
|
It is currently only available for JavaScript
|
|
|
|
and disabled by default ``TCS_None``.
|
|
|
|
``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
|
|
|
|
as inserting the comma disables bin-packing.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
TSC_Wrapped:
|
|
|
|
const someArray = [
|
|
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaa,
|
|
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaa,
|
|
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaa,
|
|
|
|
// ^ inserted
|
|
|
|
]
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``TCS_None`` (in configuration: ``None``)
|
|
|
|
Do not insert trailing commas.
|
|
|
|
|
|
|
|
* ``TCS_Wrapped`` (in configuration: ``Wrapped``)
|
|
|
|
Insert trailing commas in container literals that were wrapped over
|
|
|
|
multiple lines. Note that this is conceptually incompatible with
|
|
|
|
bin-packing, because the trailing comma is used as an indicator
|
|
|
|
that a container should be formatted one-per-line (i.e. not bin-packed).
|
|
|
|
So inserting a trailing comma counteracts bin-packing.
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-23 02:48:58 +08:00
|
|
|
**JavaImportGroups** (``std::vector<std::string>``)
|
|
|
|
A vector of prefixes ordered by the desired groups for Java imports.
|
|
|
|
|
2019-01-01 20:51:14 +08:00
|
|
|
Each group is separated by a newline. Static imports will also follow the
|
2018-10-23 02:48:58 +08:00
|
|
|
same grouping convention above all non-static imports. One group's prefix
|
|
|
|
can be a subset of another - the longest prefix is always matched. Within
|
|
|
|
a group, the imports are ordered lexicographically.
|
|
|
|
|
2018-10-23 03:07:29 +08:00
|
|
|
In the .clang-format configuration file, this can be configured like
|
|
|
|
in the following yaml example. This will result in imports being
|
|
|
|
formatted as in the Java example below.
|
2018-10-23 02:48:58 +08:00
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
JavaImportGroups: ['com.example', 'com', 'org']
|
2018-10-23 03:07:29 +08:00
|
|
|
|
2018-10-23 02:48:58 +08:00
|
|
|
|
|
|
|
.. code-block:: java
|
|
|
|
|
|
|
|
import static com.example.function1;
|
|
|
|
|
|
|
|
import static com.test.function2;
|
|
|
|
|
|
|
|
import static org.example.function3;
|
|
|
|
|
|
|
|
import com.example.ClassA;
|
|
|
|
import com.example.Test;
|
|
|
|
import com.example.a.ClassB;
|
|
|
|
|
|
|
|
import com.test.ClassC;
|
|
|
|
|
|
|
|
import org.example.ClassD;
|
|
|
|
|
2016-03-21 22:11:27 +08:00
|
|
|
**JavaScriptQuotes** (``JavaScriptQuoteStyle``)
|
|
|
|
The JavaScriptQuoteStyle to use for JavaScript strings.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``JSQS_Leave`` (in configuration: ``Leave``)
|
|
|
|
Leave string quotes as they are.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: js
|
|
|
|
|
|
|
|
string1 = "foo";
|
|
|
|
string2 = 'bar';
|
|
|
|
|
2016-03-21 22:11:27 +08:00
|
|
|
* ``JSQS_Single`` (in configuration: ``Single``)
|
|
|
|
Always use single quotes.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: js
|
|
|
|
|
|
|
|
string1 = 'foo';
|
|
|
|
string2 = 'bar';
|
|
|
|
|
2016-03-21 22:11:27 +08:00
|
|
|
* ``JSQS_Double`` (in configuration: ``Double``)
|
|
|
|
Always use double quotes.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: js
|
|
|
|
|
|
|
|
string1 = "foo";
|
|
|
|
string2 = "bar";
|
|
|
|
|
2016-03-21 22:11:27 +08:00
|
|
|
|
|
|
|
|
2017-03-01 23:35:39 +08:00
|
|
|
**JavaScriptWrapImports** (``bool``)
|
|
|
|
Whether to wrap JavaScript import/export statements.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: js
|
|
|
|
|
|
|
|
true:
|
|
|
|
import {
|
|
|
|
VeryLongImportsAreAnnoying,
|
|
|
|
VeryLongImportsAreAnnoying,
|
|
|
|
VeryLongImportsAreAnnoying,
|
|
|
|
} from 'some/module.js'
|
|
|
|
|
|
|
|
false:
|
|
|
|
import {VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying,} from "some/module.js"
|
|
|
|
|
2014-04-09 22:05:49 +08:00
|
|
|
**KeepEmptyLinesAtTheStartOfBlocks** (``bool``)
|
2017-04-11 15:07:05 +08:00
|
|
|
If true, the empty line at the start of blocks is kept.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
if (foo) { vs. if (foo) {
|
|
|
|
bar();
|
|
|
|
bar(); }
|
|
|
|
}
|
2014-04-09 22:05:49 +08:00
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
**Language** (``LanguageKind``)
|
|
|
|
Language, this format style is targeted at.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``LK_None`` (in configuration: ``None``)
|
|
|
|
Do not use.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
* ``LK_Cpp`` (in configuration: ``Cpp``)
|
2017-03-01 23:35:39 +08:00
|
|
|
Should be used for C, C++.
|
[clang-format] Add basic support for formatting C# files
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
2019-03-21 21:09:22 +08:00
|
|
|
|
|
|
|
* ``LK_CSharp`` (in configuration: ``CSharp``)
|
|
|
|
Should be used for C#.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2014-10-09 17:52:05 +08:00
|
|
|
* ``LK_Java`` (in configuration: ``Java``)
|
|
|
|
Should be used for Java.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
* ``LK_JavaScript`` (in configuration: ``JavaScript``)
|
|
|
|
Should be used for JavaScript.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-01 23:35:39 +08:00
|
|
|
* ``LK_ObjC`` (in configuration: ``ObjC``)
|
|
|
|
Should be used for Objective-C, Objective-C++.
|
|
|
|
|
2014-02-13 20:51:50 +08:00
|
|
|
* ``LK_Proto`` (in configuration: ``Proto``)
|
|
|
|
Should be used for Protocol Buffers
|
|
|
|
(https://developers.google.com/protocol-buffers/).
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2016-02-24 00:11:51 +08:00
|
|
|
* ``LK_TableGen`` (in configuration: ``TableGen``)
|
|
|
|
Should be used for TableGen code.
|
2013-12-10 18:18:34 +08:00
|
|
|
|
2017-09-07 20:08:49 +08:00
|
|
|
* ``LK_TextProto`` (in configuration: ``TextProto``)
|
|
|
|
Should be used for Protocol Buffer messages in text format
|
|
|
|
(https://developers.google.com/protocol-buffers/).
|
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2015-07-04 01:25:16 +08:00
|
|
|
**MacroBlockBegin** (``std::string``)
|
|
|
|
A regular expression matching macros that start a block.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
# With:
|
|
|
|
MacroBlockBegin: "^NS_MAP_BEGIN|\
|
|
|
|
NS_TABLE_HEAD$"
|
|
|
|
MacroBlockEnd: "^\
|
|
|
|
NS_MAP_END|\
|
|
|
|
NS_TABLE_.*_END$"
|
|
|
|
|
|
|
|
NS_MAP_BEGIN
|
|
|
|
foo();
|
|
|
|
NS_MAP_END
|
|
|
|
|
|
|
|
NS_TABLE_HEAD
|
|
|
|
bar();
|
|
|
|
NS_TABLE_FOO_END
|
|
|
|
|
|
|
|
# Without:
|
|
|
|
NS_MAP_BEGIN
|
|
|
|
foo();
|
|
|
|
NS_MAP_END
|
|
|
|
|
|
|
|
NS_TABLE_HEAD
|
|
|
|
bar();
|
|
|
|
NS_TABLE_FOO_END
|
|
|
|
|
2015-07-04 01:25:16 +08:00
|
|
|
**MacroBlockEnd** (``std::string``)
|
|
|
|
A regular expression matching macros that end a block.
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**MaxEmptyLinesToKeep** (``unsigned``)
|
|
|
|
The maximum number of consecutive empty lines to keep.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
MaxEmptyLinesToKeep: 1 vs. MaxEmptyLinesToKeep: 0
|
|
|
|
int f() { int f() {
|
|
|
|
int = 1; int i = 1;
|
|
|
|
i = foo();
|
|
|
|
i = foo(); return i;
|
|
|
|
}
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**NamespaceIndentation** (``NamespaceIndentationKind``)
|
|
|
|
The indentation used for namespaces.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``NI_None`` (in configuration: ``None``)
|
|
|
|
Don't indent in namespaces.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
namespace out {
|
|
|
|
int i;
|
|
|
|
namespace in {
|
|
|
|
int i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``NI_Inner`` (in configuration: ``Inner``)
|
|
|
|
Indent only in inner namespaces (nested in other namespaces).
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
namespace out {
|
|
|
|
int i;
|
|
|
|
namespace in {
|
|
|
|
int i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``NI_All`` (in configuration: ``All``)
|
|
|
|
Indent in all namespaces.
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
namespace out {
|
|
|
|
int i;
|
|
|
|
namespace in {
|
|
|
|
int i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2019-06-07 04:06:23 +08:00
|
|
|
**NamespaceMacros** (``std::vector<std::string>``)
|
|
|
|
A vector of macros which are used to open namespace blocks.
|
|
|
|
|
|
|
|
These are expected to be macros of the form:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
NAMESPACE(<namespace-name>, ...) {
|
|
|
|
<namespace-content>
|
|
|
|
}
|
|
|
|
|
|
|
|
For example: TESTSUITE
|
|
|
|
|
2018-03-06 21:24:01 +08:00
|
|
|
**ObjCBinPackProtocolList** (``BinPackStyle``)
|
|
|
|
Controls bin-packing Objective-C protocol conformance list
|
|
|
|
items into as few lines as possible when they go over ``ColumnLimit``.
|
|
|
|
|
|
|
|
If ``Auto`` (the default), delegates to the value in
|
|
|
|
``BinPackParameters``. If that is ``true``, bin-packs Objective-C
|
|
|
|
protocol conformance list items into as few lines as possible
|
|
|
|
whenever they go over ``ColumnLimit``.
|
|
|
|
|
|
|
|
If ``Always``, always bin-packs Objective-C protocol conformance
|
|
|
|
list items into as few lines as possible whenever they go over
|
|
|
|
``ColumnLimit``.
|
|
|
|
|
|
|
|
If ``Never``, lays out Objective-C protocol conformance list items
|
|
|
|
onto individual lines whenever they go over ``ColumnLimit``.
|
|
|
|
|
|
|
|
|
2018-06-28 20:02:38 +08:00
|
|
|
.. code-block:: objc
|
2018-03-06 21:24:01 +08:00
|
|
|
|
|
|
|
Always (or Auto, if BinPackParameters=true):
|
|
|
|
@interface ccccccccccccc () <
|
|
|
|
ccccccccccccc, ccccccccccccc,
|
|
|
|
ccccccccccccc, ccccccccccccc> {
|
|
|
|
}
|
|
|
|
|
|
|
|
Never (or Auto, if BinPackParameters=false):
|
|
|
|
@interface ddddddddddddd () <
|
|
|
|
ddddddddddddd,
|
|
|
|
ddddddddddddd,
|
|
|
|
ddddddddddddd,
|
|
|
|
ddddddddddddd> {
|
|
|
|
}
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``BPS_Auto`` (in configuration: ``Auto``)
|
|
|
|
Automatically determine parameter bin-packing behavior.
|
|
|
|
|
|
|
|
* ``BPS_Always`` (in configuration: ``Always``)
|
|
|
|
Always bin-pack parameters.
|
|
|
|
|
|
|
|
* ``BPS_Never`` (in configuration: ``Never``)
|
|
|
|
Never bin-pack parameters.
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-29 00:56:37 +08:00
|
|
|
**ObjCBlockIndentWidth** (``unsigned``)
|
|
|
|
The number of characters to use for indentation of ObjC blocks.
|
|
|
|
|
2017-04-11 15:07:05 +08:00
|
|
|
.. code-block:: objc
|
|
|
|
|
|
|
|
ObjCBlockIndentWidth: 4
|
|
|
|
|
|
|
|
[operation setCompletionBlock:^{
|
|
|
|
[self onOperationDone];
|
|
|
|
}];
|
|
|
|
|
[clang-format] Add option for not breaking line before ObjC params
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
2020-02-02 01:37:25 +08:00
|
|
|
**ObjCBreakBeforeNestedBlockParam** (``bool``)
|
|
|
|
Break parameters list into lines when there is nested block
|
2020-09-16 20:45:45 +08:00
|
|
|
parameters in a function call.
|
[clang-format] Add option for not breaking line before ObjC params
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
2020-02-02 01:37:25 +08:00
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
false:
|
|
|
|
- (void)_aMethod
|
|
|
|
{
|
2020-04-30 17:47:23 +08:00
|
|
|
[self.test1 t:self w:self callback:^(typeof(self) self, NSNumber
|
|
|
|
*u, NSNumber *v) {
|
[clang-format] Add option for not breaking line before ObjC params
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
2020-02-02 01:37:25 +08:00
|
|
|
u = c;
|
|
|
|
}]
|
|
|
|
}
|
|
|
|
true:
|
|
|
|
- (void)_aMethod
|
|
|
|
{
|
|
|
|
[self.test1 t:self
|
2020-04-30 17:47:23 +08:00
|
|
|
w:self
|
|
|
|
callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
|
[clang-format] Add option for not breaking line before ObjC params
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
2020-02-02 01:37:25 +08:00
|
|
|
u = c;
|
|
|
|
}]
|
|
|
|
}
|
|
|
|
|
2014-02-13 20:51:50 +08:00
|
|
|
**ObjCSpaceAfterProperty** (``bool``)
|
|
|
|
Add a space after ``@property`` in Objective-C, i.e. use
|
2016-02-24 00:12:00 +08:00
|
|
|
``@property (readonly)`` instead of ``@property(readonly)``.
|
2014-02-13 20:51:50 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**ObjCSpaceBeforeProtocolList** (``bool``)
|
|
|
|
Add a space in front of an Objective-C protocol list, i.e. use
|
|
|
|
``Foo <Protocol>`` instead of ``Foo<Protocol>``.
|
|
|
|
|
2017-06-23 16:48:00 +08:00
|
|
|
**PenaltyBreakAssignment** (``unsigned``)
|
|
|
|
The penalty for breaking around an assignment operator.
|
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
**PenaltyBreakBeforeFirstCallParameter** (``unsigned``)
|
2016-02-24 00:12:00 +08:00
|
|
|
The penalty for breaking a function call after ``call(``.
|
2013-12-10 18:18:34 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**PenaltyBreakComment** (``unsigned``)
|
|
|
|
The penalty for each line break introduced inside a comment.
|
|
|
|
|
|
|
|
**PenaltyBreakFirstLessLess** (``unsigned``)
|
|
|
|
The penalty for breaking before the first ``<<``.
|
|
|
|
|
|
|
|
**PenaltyBreakString** (``unsigned``)
|
|
|
|
The penalty for each line break introduced inside a string literal.
|
|
|
|
|
2018-05-16 16:25:03 +08:00
|
|
|
**PenaltyBreakTemplateDeclaration** (``unsigned``)
|
|
|
|
The penalty for breaking after template declaration.
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**PenaltyExcessCharacter** (``unsigned``)
|
|
|
|
The penalty for each character outside of the column limit.
|
|
|
|
|
|
|
|
**PenaltyReturnTypeOnItsOwnLine** (``unsigned``)
|
|
|
|
Penalty for putting the return type of a function onto its own
|
|
|
|
line.
|
|
|
|
|
2014-06-17 20:40:34 +08:00
|
|
|
**PointerAlignment** (``PointerAlignmentStyle``)
|
|
|
|
Pointer and reference alignment style.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``PAS_Left`` (in configuration: ``Left``)
|
|
|
|
Align pointer to the left.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-03-09 14:41:08 +08:00
|
|
|
int* a;
|
2017-03-08 21:24:46 +08:00
|
|
|
|
2014-06-17 20:40:34 +08:00
|
|
|
* ``PAS_Right`` (in configuration: ``Right``)
|
|
|
|
Align pointer to the right.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-03-09 14:41:08 +08:00
|
|
|
int *a;
|
2017-03-08 21:24:46 +08:00
|
|
|
|
2014-06-17 20:40:34 +08:00
|
|
|
* ``PAS_Middle`` (in configuration: ``Middle``)
|
|
|
|
Align pointer in the middle.
|
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
2017-03-09 14:41:08 +08:00
|
|
|
int * a;
|
2017-03-08 21:24:46 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-11-09 23:41:23 +08:00
|
|
|
**RawStringFormats** (``std::vector<RawStringFormat>``)
|
2018-01-18 00:17:26 +08:00
|
|
|
Defines hints for detecting supported languages code blocks in raw
|
|
|
|
strings.
|
|
|
|
|
|
|
|
A raw string with a matching delimiter or a matching enclosing function
|
|
|
|
name will be reformatted assuming the specified language based on the
|
|
|
|
style for that language defined in the .clang-format file. If no style has
|
|
|
|
been defined in the .clang-format file for the specific language, a
|
|
|
|
predefined style given by 'BasedOnStyle' is used. If 'BasedOnStyle' is not
|
|
|
|
found, the formatting is based on llvm style. A matching delimiter takes
|
|
|
|
precedence over a matching enclosing function name for determining the
|
|
|
|
language of the raw string contents.
|
2017-11-09 23:41:23 +08:00
|
|
|
|
2018-01-24 18:26:09 +08:00
|
|
|
If a canonical delimiter is specified, occurrences of other delimiters for
|
2018-01-20 00:18:47 +08:00
|
|
|
the same language will be updated to the canonical if possible.
|
|
|
|
|
2018-01-18 00:17:26 +08:00
|
|
|
There should be at most one specification per language and each delimiter
|
|
|
|
and enclosing function should not occur in multiple specifications.
|
2017-11-09 23:41:23 +08:00
|
|
|
|
|
|
|
To configure this in the .clang-format file, use:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
RawStringFormats:
|
2018-01-18 00:17:26 +08:00
|
|
|
- Language: TextProto
|
|
|
|
Delimiters:
|
|
|
|
- 'pb'
|
|
|
|
- 'proto'
|
|
|
|
EnclosingFunctions:
|
|
|
|
- 'PARSE_TEXT_PROTO'
|
|
|
|
BasedOnStyle: google
|
|
|
|
- Language: Cpp
|
|
|
|
Delimiters:
|
|
|
|
- 'cc'
|
|
|
|
- 'cpp'
|
|
|
|
BasedOnStyle: llvm
|
2018-01-20 00:18:47 +08:00
|
|
|
CanonicalDelimiter: 'cc'
|
2017-11-09 23:41:23 +08:00
|
|
|
|
2016-02-24 00:11:51 +08:00
|
|
|
**ReflowComments** (``bool``)
|
2016-02-24 00:12:00 +08:00
|
|
|
If ``true``, clang-format will attempt to re-flow comments.
|
2016-02-24 00:11:51 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
false:
|
|
|
|
// veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
|
|
|
|
/* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information */
|
|
|
|
|
|
|
|
true:
|
|
|
|
// veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
|
|
|
|
// information
|
|
|
|
/* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
|
|
|
|
* information */
|
|
|
|
|
2016-02-24 00:11:51 +08:00
|
|
|
**SortIncludes** (``bool``)
|
2016-02-24 00:12:00 +08:00
|
|
|
If ``true``, clang-format will sort ``#includes``.
|
2016-02-24 00:11:51 +08:00
|
|
|
|
2017-03-08 21:24:46 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
false: true:
|
|
|
|
#include "b.h" vs. #include "a.h"
|
|
|
|
#include "a.h" #include "b.h"
|
|
|
|
|
2017-06-23 19:46:03 +08:00
|
|
|
**SortUsingDeclarations** (``bool``)
|
|
|
|
If ``true``, clang-format will sort using declarations.
|
|
|
|
|
2017-11-09 23:41:23 +08:00
|
|
|
The order of using declarations is defined as follows:
|
|
|
|
Split the strings by "::" and discard any initial empty strings. The last
|
|
|
|
element of each list is a non-namespace name; all others are namespace
|
|
|
|
names. Sort the lists of names lexicographically, where the sort order of
|
|
|
|
individual names is that all non-namespace names come before all namespace
|
|
|
|
names, and within those groups, names are in case-insensitive
|
|
|
|
lexicographic order.
|
2017-06-23 19:46:03 +08:00
|
|
|
|
2017-11-09 23:54:59 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
false: true:
|
|
|
|
using std::cout; vs. using std::cin;
|
|
|
|
using std::cin; using std::cout;
|
|
|
|
|
2014-09-10 21:11:45 +08:00
|
|
|
**SpaceAfterCStyleCast** (``bool``)
|
2017-03-08 21:24:46 +08:00
|
|
|
If ``true``, a space is inserted after C style casts.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
2018-03-06 21:24:01 +08:00
|
|
|
(int) i; vs. (int)i;
|
2014-09-10 21:11:45 +08:00
|
|
|
|
2019-04-08 20:54:48 +08:00
|
|
|
**SpaceAfterLogicalNot** (``bool``)
|
|
|
|
If ``true``, a space is inserted after the logical not operator (``!``).
|
2019-04-09 07:36:25 +08:00
|
|
|
|
2019-04-08 20:54:48 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
! someExpression(); vs. !someExpression();
|
|
|
|
|
2016-08-09 22:24:40 +08:00
|
|
|
**SpaceAfterTemplateKeyword** (``bool``)
|
|
|
|
If ``true``, a space will be inserted after the 'template' keyword.
|
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
template <int> void foo(); vs. template<int> void foo();
|
|
|
|
|
2013-09-25 23:15:02 +08:00
|
|
|
**SpaceBeforeAssignmentOperators** (``bool``)
|
2013-09-28 00:16:55 +08:00
|
|
|
If ``false``, spaces will be removed before assignment operators.
|
2013-09-25 23:15:02 +08:00
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
2019-08-19 02:51:39 +08:00
|
|
|
int a = 5; vs. int a= 5;
|
|
|
|
a += 42; a+= 42;
|
2017-03-07 00:35:28 +08:00
|
|
|
|
2018-06-14 16:01:09 +08:00
|
|
|
**SpaceBeforeCpp11BracedList** (``bool``)
|
|
|
|
If ``true``, a space will be inserted before a C++11 braced list
|
|
|
|
used to initialize an object (after the preceding identifier or type).
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
Foo foo { bar }; vs. Foo foo{ bar };
|
|
|
|
Foo {}; Foo{};
|
|
|
|
vector<int> { 1, 2, 3 }; vector<int>{ 1, 2, 3 };
|
|
|
|
new int[3] { 1, 2, 3 }; new int[3]{ 1, 2, 3 };
|
|
|
|
|
[clang-format] Add SpaceBeforeColon option
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
2018-03-01 18:09:13 +08:00
|
|
|
**SpaceBeforeCtorInitializerColon** (``bool``)
|
|
|
|
If ``false``, spaces will be removed before constructor initializer
|
|
|
|
colon.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
Foo::Foo() : a(a) {} Foo::Foo(): a(a) {}
|
|
|
|
|
|
|
|
**SpaceBeforeInheritanceColon** (``bool``)
|
|
|
|
If ``false``, spaces will be removed before inheritance colon.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
class Foo : Bar {} vs. class Foo: Bar {}
|
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
**SpaceBeforeParens** (``SpaceBeforeParensOptions``)
|
|
|
|
Defines in which cases to put a space before opening parentheses.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``SBPO_Never`` (in configuration: ``Never``)
|
|
|
|
Never put a space before opening parentheses.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
void f() {
|
|
|
|
if(true) {
|
|
|
|
f();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
* ``SBPO_ControlStatements`` (in configuration: ``ControlStatements``)
|
|
|
|
Put a space before opening parentheses only after control statement
|
|
|
|
keywords (``for/if/while...``).
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
void f() {
|
|
|
|
if (true) {
|
|
|
|
f();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-26 20:04:45 +08:00
|
|
|
* ``SBPO_ControlStatementsExceptForEachMacros`` (in configuration: ``ControlStatementsExceptForEachMacros``)
|
|
|
|
Same as ``SBPO_ControlStatements`` except this option doesn't apply to
|
|
|
|
ForEach macros. This is useful in projects where ForEach macros are
|
|
|
|
treated as function calls instead of control statements.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
void f() {
|
|
|
|
Q_FOREACH(...) {
|
|
|
|
f();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-09 07:36:25 +08:00
|
|
|
* ``SBPO_NonEmptyParentheses`` (in configuration: ``NonEmptyParentheses``)
|
|
|
|
Put a space before opening parentheses only if the parentheses are not
|
|
|
|
empty i.e. '()'
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
void() {
|
|
|
|
if (true) {
|
|
|
|
f();
|
|
|
|
g (x, y, z);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
* ``SBPO_Always`` (in configuration: ``Always``)
|
|
|
|
Always put a space before opening parentheses, except when it's
|
|
|
|
prohibited by the syntax rules (in function-like macro definitions) or
|
|
|
|
when determined by other style rules (after unary operators, opening
|
|
|
|
parentheses, etc.)
|
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
void f () {
|
|
|
|
if (true) {
|
|
|
|
f ();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
[clang-format] Add SpaceBeforeColon option
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
2018-03-01 18:09:13 +08:00
|
|
|
**SpaceBeforeRangeBasedForLoopColon** (``bool``)
|
|
|
|
If ``false``, spaces will be removed before range-based for loop
|
|
|
|
colon.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
for (auto v : values) {} vs. for(auto v: values) {}
|
|
|
|
|
2019-11-16 19:54:21 +08:00
|
|
|
**SpaceBeforeSquareBrackets** (``bool``)
|
|
|
|
If ``true``, spaces will be before ``[``.
|
|
|
|
Lambdas will not be affected. Only the first ``[`` will get a space added.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
int a [5]; vs. int a[5];
|
|
|
|
int a [5][5]; vs. int a[5][5];
|
|
|
|
|
2019-08-10 15:51:21 +08:00
|
|
|
**SpaceInEmptyBlock** (``bool``)
|
|
|
|
If ``true``, spaces will be inserted into ``{}``.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
void f() { } vs. void f() {}
|
|
|
|
while (true) { } while (true) {}
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**SpaceInEmptyParentheses** (``bool``)
|
2016-02-24 00:12:00 +08:00
|
|
|
If ``true``, spaces may be inserted into ``()``.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
void f( ) { vs. void f() {
|
|
|
|
int x[] = {foo( ), bar( )}; int x[] = {foo(), bar()};
|
|
|
|
if (true) { if (true) {
|
|
|
|
f( ); f();
|
|
|
|
} }
|
|
|
|
} }
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**SpacesBeforeTrailingComments** (``unsigned``)
|
2014-05-15 21:55:19 +08:00
|
|
|
The number of spaces before trailing line comments
|
|
|
|
(``//`` - comments).
|
2014-04-09 22:05:49 +08:00
|
|
|
|
2016-02-27 22:02:08 +08:00
|
|
|
This does not affect trailing block comments (``/*`` - comments) as
|
2016-02-24 00:12:00 +08:00
|
|
|
those commonly have different usage patterns and a number of special
|
|
|
|
cases.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
SpacesBeforeTrailingComments: 3
|
|
|
|
void f() {
|
|
|
|
if (true) { // foo1
|
|
|
|
f(); // bar
|
|
|
|
} // foo
|
|
|
|
}
|
|
|
|
|
2013-12-10 18:18:34 +08:00
|
|
|
**SpacesInAngles** (``bool``)
|
2016-02-24 00:12:00 +08:00
|
|
|
If ``true``, spaces will be inserted after ``<`` and before ``>``
|
|
|
|
in template argument lists.
|
2013-12-10 18:18:34 +08:00
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
static_cast< int >(arg); vs. static_cast<int>(arg);
|
|
|
|
std::function< void(int) > fct; std::function<void(int)> fct;
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**SpacesInCStyleCastParentheses** (``bool``)
|
2014-02-13 20:51:50 +08:00
|
|
|
If ``true``, spaces may be inserted into C style casts.
|
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
x = ( int32 )y vs. x = (int32)y
|
|
|
|
|
2019-12-04 01:20:30 +08:00
|
|
|
**SpacesInConditionalStatement** (``bool``)
|
2020-01-19 23:52:26 +08:00
|
|
|
If ``true``, spaces will be inserted around if/for/switch/while
|
|
|
|
conditions.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
if ( a ) { ... } vs. if (a) { ... }
|
|
|
|
while ( i < 5 ) { ... } while (i < 5) { ... }
|
2019-12-04 01:20:30 +08:00
|
|
|
|
2014-02-13 20:51:50 +08:00
|
|
|
**SpacesInContainerLiterals** (``bool``)
|
|
|
|
If ``true``, spaces are inserted inside container literals (e.g.
|
|
|
|
ObjC and Javascript array and dict literals).
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-03-20 20:56:40 +08:00
|
|
|
.. code-block:: js
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
var arr = [ 1, 2, 3 ]; vs. var arr = [1, 2, 3];
|
|
|
|
f({a : 1, b : 2, c : 3}); f({a: 1, b: 2, c: 3});
|
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**SpacesInParentheses** (``bool``)
|
2016-02-24 00:12:00 +08:00
|
|
|
If ``true``, spaces will be inserted after ``(`` and before ``)``.
|
2013-09-04 23:09:13 +08:00
|
|
|
|
2017-03-07 00:35:28 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
t f( Deleted & ) & = delete; vs. t f(Deleted &) & = delete;
|
|
|
|
|
2014-08-26 19:41:14 +08:00
|
|
|
**SpacesInSquareBrackets** (``bool``)
|
2016-02-24 00:12:00 +08:00
|
|
|
If ``true``, spaces will be inserted after ``[`` and before ``]``.
|
2019-11-07 04:02:16 +08:00
|
|
|
Lambdas without arguments or unspecified size array declarations will not
|
|
|
|
be affected.
|
2017-03-07 00:35:28 +08:00
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
true: false:
|
|
|
|
int a[ 5 ]; vs. int a[5];
|
|
|
|
std::unique_ptr<int[]> foo() {} // Won't be affected
|
2014-08-26 19:41:14 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
**Standard** (``LanguageStandard``)
|
2019-10-04 17:52:54 +08:00
|
|
|
Parse and format C++ constructs compatible with this standard.
|
|
|
|
|
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
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
2019-10-02 17:50:40 +08:00
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
c++03: latest:
|
|
|
|
vector<set<int> > x; vs. vector<set<int>> x;
|
2013-09-04 23:09:13 +08:00
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
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
2019-10-02 17:50:40 +08:00
|
|
|
* ``LS_Cpp03`` (in configuration: ``c++03``)
|
2019-11-07 04:02:16 +08:00
|
|
|
Parse and format as C++03.
|
|
|
|
``Cpp03`` is a deprecated alias for ``c++03``
|
2016-02-24 00:12:00 +08:00
|
|
|
|
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
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
2019-10-02 17:50:40 +08:00
|
|
|
* ``LS_Cpp11`` (in configuration: ``c++11``)
|
2019-11-07 04:02:16 +08:00
|
|
|
Parse and format as C++11.
|
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
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
2019-10-02 17:50:40 +08:00
|
|
|
|
|
|
|
* ``LS_Cpp14`` (in configuration: ``c++14``)
|
2019-11-07 04:02:16 +08:00
|
|
|
Parse and format as C++14.
|
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
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
2019-10-02 17:50:40 +08:00
|
|
|
|
|
|
|
* ``LS_Cpp17`` (in configuration: ``c++17``)
|
2019-11-07 04:02:16 +08:00
|
|
|
Parse and format as C++17.
|
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
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
2019-10-02 17:50:40 +08:00
|
|
|
|
|
|
|
* ``LS_Cpp20`` (in configuration: ``c++20``)
|
2019-11-07 04:02:16 +08:00
|
|
|
Parse and format as C++20.
|
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
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
2019-10-02 17:50:40 +08:00
|
|
|
|
|
|
|
* ``LS_Latest`` (in configuration: ``Latest``)
|
|
|
|
Parse and format using the latest supported language version.
|
2019-11-07 04:02:16 +08:00
|
|
|
``Cpp11`` is a deprecated alias for ``Latest``
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
* ``LS_Auto`` (in configuration: ``Auto``)
|
|
|
|
Automatic detection based on the input.
|
|
|
|
|
|
|
|
|
2016-02-24 00:12:00 +08:00
|
|
|
|
clang-format: better handle statement macros
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
2018-10-03 00:37:51 +08:00
|
|
|
**StatementMacros** (``std::vector<std::string>``)
|
2018-10-23 02:48:58 +08:00
|
|
|
A vector of macros that should be interpreted as complete
|
|
|
|
statements.
|
clang-format: better handle statement macros
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
2018-10-03 00:37:51 +08:00
|
|
|
|
|
|
|
Typical macros are expressions, and require a semi-colon to be
|
|
|
|
added; sometimes this is not the case, and this allows to make
|
|
|
|
clang-format aware of such cases.
|
|
|
|
|
|
|
|
For example: Q_UNUSED
|
|
|
|
|
2013-09-28 00:16:55 +08:00
|
|
|
**TabWidth** (``unsigned``)
|
|
|
|
The number of columns used for tab stops.
|
|
|
|
|
2019-08-10 15:51:21 +08:00
|
|
|
**TypenameMacros** (``std::vector<std::string>``)
|
|
|
|
A vector of macros that should be interpreted as type declarations
|
|
|
|
instead of as function calls.
|
|
|
|
|
|
|
|
These are expected to be macros of the form:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
STACK_OF(...)
|
|
|
|
|
|
|
|
In the .clang-format configuration file, this can be configured like:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
TypenameMacros: ['STACK_OF', 'LIST']
|
|
|
|
|
|
|
|
For example: OpenSSL STACK_OF, BSD LIST_ENTRY.
|
|
|
|
|
2019-11-16 19:54:21 +08:00
|
|
|
**UseCRLF** (``bool``)
|
|
|
|
Use ``\r\n`` instead of ``\n`` for line breaks.
|
|
|
|
Also used as fallback if ``DeriveLineEnding`` is true.
|
|
|
|
|
2013-09-28 00:16:55 +08:00
|
|
|
**UseTab** (``UseTabStyle``)
|
|
|
|
The way to use tab characters in the resulting file.
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
|
|
|
* ``UT_Never`` (in configuration: ``Never``)
|
|
|
|
Never use tab.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2013-09-28 00:16:55 +08:00
|
|
|
* ``UT_ForIndentation`` (in configuration: ``ForIndentation``)
|
|
|
|
Use tabs only for indentation.
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2017-03-01 23:35:39 +08:00
|
|
|
* ``UT_ForContinuationAndIndentation`` (in configuration: ``ForContinuationAndIndentation``)
|
2020-04-13 22:14:26 +08:00
|
|
|
Fill all leading whitespace with tabs, and use spaces for alignment that
|
|
|
|
appears within a line (e.g. consecutive assignments and declarations).
|
|
|
|
|
|
|
|
* ``UT_AlignWithSpaces`` (in configuration: ``AlignWithSpaces``)
|
2020-04-30 17:47:23 +08:00
|
|
|
Use tabs for line continuation and indentation, and spaces for
|
|
|
|
alignment.
|
2017-03-01 23:35:39 +08:00
|
|
|
|
2013-09-28 00:16:55 +08:00
|
|
|
* ``UT_Always`` (in configuration: ``Always``)
|
|
|
|
Use tabs whenever we need to fill whitespace that spans at least from
|
|
|
|
one tab stop to the next one.
|
|
|
|
|
2020-07-18 23:26:06 +08:00
|
|
|
|
|
|
|
|
[clang-format] Preserve whitespace in selected macros
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
2020-06-26 09:59:33 +08:00
|
|
|
**WhitespaceSensitiveMacros** (``std::vector<std::string>``)
|
2020-07-18 23:26:06 +08:00
|
|
|
A vector of macros which are whitespace-sensitive and should not
|
|
|
|
be touched.
|
[clang-format] Preserve whitespace in selected macros
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
2020-06-26 09:59:33 +08:00
|
|
|
|
|
|
|
These are expected to be macros of the form:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
STRINGIZE(...)
|
|
|
|
|
|
|
|
In the .clang-format configuration file, this can be configured like:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
WhitespaceSensitiveMacros: ['STRINGIZE', 'PP_STRINGIZE']
|
|
|
|
|
2020-07-18 23:26:06 +08:00
|
|
|
For example: BOOST_PP_STRINGIZE
|
2016-02-24 00:12:00 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
.. END_FORMAT_STYLE_OPTIONS
|
|
|
|
|
2015-10-05 15:24:55 +08:00
|
|
|
Adding additional style options
|
|
|
|
===============================
|
|
|
|
|
|
|
|
Each additional style option adds costs to the clang-format project. Some of
|
2016-02-15 04:20:58 +08:00
|
|
|
these costs affect the clang-format development itself, as we need to make
|
2015-10-05 15:24:55 +08:00
|
|
|
sure that any given combination of options work and that new features don't
|
|
|
|
break any of the existing options in any way. There are also costs for end users
|
|
|
|
as options become less discoverable and people have to think about and make a
|
|
|
|
decision on options they don't really care about.
|
|
|
|
|
|
|
|
The goal of the clang-format project is more on the side of supporting a
|
|
|
|
limited set of styles really well as opposed to supporting every single style
|
|
|
|
used by a codebase somewhere in the wild. Of course, we do want to support all
|
|
|
|
major projects and thus have established the following bar for adding style
|
|
|
|
options. Each new style option must ..
|
|
|
|
|
2015-10-05 21:30:42 +08:00
|
|
|
* be used in a project of significant size (have dozens of contributors)
|
|
|
|
* have a publicly accessible style guide
|
|
|
|
* have a person willing to contribute and maintain patches
|
2015-10-05 15:24:55 +08:00
|
|
|
|
2013-09-04 23:09:13 +08:00
|
|
|
Examples
|
|
|
|
========
|
|
|
|
|
|
|
|
A style similar to the `Linux Kernel style
|
|
|
|
<https://www.kernel.org/doc/Documentation/CodingStyle>`_:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
BasedOnStyle: LLVM
|
|
|
|
IndentWidth: 8
|
2013-09-28 00:19:25 +08:00
|
|
|
UseTab: Always
|
2013-09-04 23:09:13 +08:00
|
|
|
BreakBeforeBraces: Linux
|
|
|
|
AllowShortIfStatementsOnASingleLine: false
|
|
|
|
IndentCaseLabels: false
|
|
|
|
|
|
|
|
The result is (imagine that tabs are used for indentation here):
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
void test()
|
|
|
|
{
|
|
|
|
switch (x) {
|
|
|
|
case 0:
|
|
|
|
case 1:
|
|
|
|
do_something();
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
do_something_else();
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (condition)
|
|
|
|
do_something_completely_different();
|
|
|
|
|
|
|
|
if (x == y) {
|
|
|
|
q();
|
|
|
|
} else if (x > y) {
|
|
|
|
w();
|
|
|
|
} else {
|
|
|
|
r();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
A style similar to the default Visual Studio formatting style:
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
2013-09-28 00:19:25 +08:00
|
|
|
UseTab: Never
|
2013-09-04 23:09:13 +08:00
|
|
|
IndentWidth: 4
|
|
|
|
BreakBeforeBraces: Allman
|
|
|
|
AllowShortIfStatementsOnASingleLine: false
|
|
|
|
IndentCaseLabels: false
|
|
|
|
ColumnLimit: 0
|
|
|
|
|
|
|
|
The result is:
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
void test()
|
|
|
|
{
|
|
|
|
switch (suffix)
|
|
|
|
{
|
|
|
|
case 0:
|
|
|
|
case 1:
|
|
|
|
do_something();
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
do_something_else();
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (condition)
|
|
|
|
do_somthing_completely_different();
|
|
|
|
|
|
|
|
if (x == y)
|
|
|
|
{
|
|
|
|
q();
|
|
|
|
}
|
|
|
|
else if (x > y)
|
|
|
|
{
|
|
|
|
w();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
r();
|
|
|
|
}
|
|
|
|
}
|