2013-01-10 05:49:28 +08:00
===========
ClangFormat
===========
`ClangFormat` describes a set of tools that are built on top of
:doc: `LibFormat` . It can support your workflow in a variety of ways including a
standalone tool and editor integrations.
Standalone Tool
===============
2013-03-22 20:44:20 +08:00
:program: `clang-format` is located in `clang/tools/clang-format` and can be used
[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
to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.
2013-01-10 05:49:28 +08:00
.. code-block :: console
2013-09-02 23:30:26 +08:00
$ clang-format -help
[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
OVERVIEW: A tool to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.
2013-01-10 05:49:28 +08:00
If no arguments are specified, it formats the code from standard input
and writes the result to the standard output.
2013-09-02 23:30:26 +08:00
If <file>s are given, it reformats the files. If -i is specified
together with <file>s, the files are edited in-place. Otherwise, the
2013-05-11 02:12:00 +08:00
result is written to the standard output.
2013-01-10 05:49:28 +08:00
2013-05-11 02:12:00 +08:00
USAGE: clang-format [options] [<file> ...]
2013-01-10 05:49:28 +08:00
OPTIONS:
2013-05-11 02:12:00 +08:00
Clang-format options:
2019-11-09 06:39:27 +08:00
--Werror - If set, changes formatting warnings to errors
2020-12-17 23:06:56 +08:00
--Wno-error=<value> - If set don't error out on the specified warning type.
=unknown - If set, unknown format options are only warned about.
This can be used to enable formatting, even if the
configuration contains unknown (newer) options.
Use with caution, as this might lead to dramatically
differing format depending on an option being
supported or not.
2019-11-13 05:15:17 +08:00
--assume-filename=<string> - Override filename used to determine the language.
When reading from stdin, clang-format assumes this
filename to determine the language.
2019-11-09 06:39:27 +08:00
--cursor=<uint> - The position of the cursor when invoking
clang-format from an editor integration
--dry-run - If set, do not actually make the formatting changes
--dump-config - Dump configuration options to stdout and exit.
Can be used with -style option.
--fallback-style=<string> - The name of the predefined style used as a
fallback in case clang-format is invoked with
-style=file, but can not find the .clang-format
file to use.
Use -fallback-style=none to skip formatting.
--ferror-limit=<uint> - Set the maximum number of clang-format errors to
emit before stopping (0 = no limit). Used only
with --dry-run or -n
-i - Inplace edit <file>s, if specified.
--length=<uint> - Format a range of this length (in bytes).
Multiple ranges can be formatted by specifying
several -offset and -length pairs.
When only a single -offset is specified without
-length, clang-format will format up to the end
of the file.
Can only be used with one input file.
--lines=<string> - <start line>:<end line> - format a range of
lines (both 1-based).
Multiple ranges can be formatted by specifying
several -lines arguments.
Can't be used with -offset and -length.
Can only be used with one input file.
-n - Alias for --dry-run
--offset=<uint> - Format a range starting at this byte offset.
Multiple ranges can be formatted by specifying
several -offset and -length pairs.
Can only be used with one input file.
--output-replacements-xml - Output replacements as XML.
--sort-includes - If set, overrides the include sorting behavior
determined by the SortIncludes style flag
--style=<string> - Coding style, currently supports:
LLVM, Google, Chromium, Mozilla, WebKit.
Use -style=file to load style configuration from
.clang-format file located in one of the parent
directories of the source file (or current
directory for stdin).
Use -style="{key: value, ...}" to set specific
parameters, e.g.:
-style="{BasedOnStyle: llvm, IndentWidth: 8}"
--verbose - If set, shows the list of processed files
2013-05-11 02:12:00 +08:00
2015-10-19 09:08:30 +08:00
Generic Options:
2013-05-11 02:12:00 +08:00
2019-11-09 06:39:27 +08:00
--help - Display available options (--help-hidden for more)
2019-11-12 04:52:08 +08:00
--help-list - Display list of available options (--help-list-hidden for more)
2019-11-09 06:39:27 +08:00
--version - Display the version of this program
2013-01-10 05:49:28 +08:00
2013-09-04 23:09:13 +08:00
When the desired code formatting style is different from the available options,
the style can be customized using the `` -style="{key: value, ...}" `` option or
2013-09-10 23:41:12 +08:00
by putting your style configuration in the `` .clang-format `` or `` _clang-format ``
file in your project's directory and using `` clang-format -style=file `` .
2013-09-04 23:09:13 +08:00
An easy way to create the `` .clang-format `` file is:
.. code-block :: console
clang-format -style=llvm -dump-config > .clang-format
Available style options are described in :doc: `ClangFormatStyleOptions` .
2013-01-10 05:49:28 +08:00
Vim Integration
===============
2013-01-10 06:18:55 +08:00
There is an integration for :program: `vim` which lets you run the
:program: `clang-format` standalone tool on your current buffer, optionally
2013-03-01 02:16:24 +08:00
selecting regions to reformat. The integration has the form of a `python` -file
2013-03-22 20:44:20 +08:00
which can be found under `clang/tools/clang-format/clang-format.py` .
2013-01-10 05:49:28 +08:00
2013-03-01 02:16:24 +08:00
This can be integrated by adding the following to your `.vimrc` :
2013-01-10 05:49:28 +08:00
2013-03-03 23:17:35 +08:00
.. code-block :: vim
2013-01-10 05:49:28 +08:00
2014-11-03 05:27:52 +08:00
map <C-K> :pyf <path-to-this-file>/clang-format.py<cr>
imap <C-K> <c-o>:pyf <path-to-this-file>/clang-format.py<cr>
2013-01-10 05:49:28 +08:00
2013-01-10 06:18:55 +08:00
The first line enables :program: `clang-format` for NORMAL and VISUAL mode, the
2013-03-22 20:44:20 +08:00
second line adds support for INSERT mode. Change "C-K" to another binding if
you need :program: `clang-format` on a different key (C-K stands for Ctrl+k).
2013-01-10 05:49:28 +08:00
With this integration you can press the bound key and clang-format will
format the current line in NORMAL and INSERT mode or the selected region in
VISUAL mode. The line or region is extended to the next bigger syntactic
entity.
It operates on the current, potentially unsaved buffer and does not create
or save any files. To revert a formatting, just undo.
2017-06-19 15:30:04 +08:00
An alternative option is to format changes when saving a file and thus to
have a zero-effort integration into the coding workflow. To do this, add this to
your `.vimrc` :
.. code-block :: vim
function! Formatonsave()
let l:formatdiff = 1
pyf ~/llvm/tools/clang/tools/clang-format/clang-format.py
endfunction
autocmd BufWritePre *.h,* .cc,*.cpp call Formatonsave()
2013-01-10 05:49:28 +08:00
2013-04-17 15:55:02 +08:00
Emacs Integration
=================
Similar to the integration for :program: `vim` , there is an integration for
:program: `emacs` . It can be found at `clang/tools/clang-format/clang-format.el`
and used by adding this to your `.emacs` :
.. code-block :: common-lisp
(load "<path-to-clang>/tools/clang-format/clang-format.el")
(global-set-key [C-M-tab] 'clang-format-region)
This binds the function `clang-format-region` to C-M-tab, which then formats the
current line or selected region.
2013-05-03 01:37:36 +08:00
BBEdit Integration
==================
:program: `clang-format` cannot be used as a text filter with BBEdit, but works
well via a script. The AppleScript to do this integration can be found at
`clang/tools/clang-format/clang-format-bbedit.applescript` ; place a copy in
`~/Library/Application Support/BBEdit/Scripts` , and edit the path within it to
point to your local copy of :program: `clang-format` .
With this integration you can select the script from the Script menu and
:program: `clang-format` will format the selection. Note that you can rename the
menu item by renaming the script, and can assign the menu item a keyboard
shortcut in the BBEdit preferences, under Menus & Shortcuts.
2019-04-03 16:56:30 +08:00
CLion Integration
2020-04-23 20:04:23 +08:00
=================
2019-04-03 16:56:30 +08:00
:program: `clang-format` is integrated into `CLion <https://www.jetbrains
2020-06-09 00:20:10 +08:00
.com/clion/>`_ as an alternative code formatter. CLion turns it on
automatically when there is a `` .clang-format `` file under the project root.
Code style rules are applied as you type, including indentation,
auto-completion, code generation, and refactorings.
:program: `clang-format` can also be enabled without a `` .clang-format `` file.
In this case, CLion prompts you to create one based on the current IDE settings
or the default LLVM style.
2019-04-03 16:56:30 +08:00
2013-09-30 01:49:50 +08:00
Visual Studio Integration
=========================
2013-12-04 08:48:22 +08:00
Download the latest Visual Studio extension from the `alpha build site
2018-11-05 01:02:00 +08:00
<https://llvm.org/builds/> `_. The default key-binding is Ctrl-R,Ctrl-F.
2013-09-30 01:49:50 +08:00
2020-04-23 20:04:23 +08:00
Visual Studio Code Integration
==============================
2020-04-23 22:46:58 +08:00
Get the latest Visual Studio Code extension from the `Visual Studio Marketplace <https://marketplace.visualstudio.com/items?itemName=xaver.clang-format> `_ . The default key-binding is Alt-Shift-F.
2020-04-23 20:04:23 +08:00
2013-01-10 05:49:28 +08:00
Script for patch reformatting
=============================
2017-04-25 01:39:35 +08:00
The python script `clang/tools/clang-format/clang-format-diff.py` parses the
output of a unified diff and reformats all contained lines with
:program: `clang-format` .
2013-01-10 05:49:28 +08:00
.. code-block :: console
2013-12-10 21:51:53 +08:00
usage: clang-format-diff.py [-h] [-i] [-p NUM] [-regex PATTERN] [-style STYLE]
2013-01-10 05:49:28 +08:00
2013-12-04 08:48:22 +08:00
Reformat changed lines in diff. Without -i option just output the diff that
would be introduced.
2013-01-10 05:49:28 +08:00
optional arguments:
2013-12-10 21:51:53 +08:00
-h, --help show this help message and exit
-i apply edits to files instead of displaying a diff
-p NUM strip the smallest prefix containing P slashes
-regex PATTERN custom pattern selecting file paths to reformat
-style STYLE formatting style to apply (LLVM, Google, Chromium, Mozilla,
WebKit)
2013-01-10 05:49:28 +08:00
2013-01-10 06:18:55 +08:00
So to reformat all the lines in the latest :program: `git` commit, just do:
2013-01-10 05:49:28 +08:00
.. code-block :: console
2016-12-04 07:22:45 +08:00
git diff -U0 --no-color HEAD^ | clang-format-diff.py -i -p1
2013-01-10 06:18:55 +08:00
2019-01-01 20:32:08 +08:00
With Mercurial/:program: `hg` :
.. code-block :: console
hg diff -U0 --color=never | clang-format-diff.py -i -p1
2014-05-14 17:36:11 +08:00
In an SVN client, you can do:
.. code-block :: console
2016-07-13 14:37:39 +08:00
svn diff --diff-cmd=diff -x -U0 | clang-format-diff.py -i
2014-05-14 17:36:11 +08:00
2016-07-14 21:01:00 +08:00
The option `-U0` will create a diff without context lines (the script would format
2013-01-10 05:49:28 +08:00
those as well).
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
2020-11-20 00:06:02 +08:00
These commands use the file paths shown in the diff output
so they will only work from the root of the repository.
[clang-format] Create a python documentation tool to generate a summary of the clang-format status for the whole of the LLVM project
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
2020-05-30 03:25:12 +08:00
Current State of Clang Format for LLVM
======================================
The following table :doc: `ClangFormattedStatus` shows the current status of clang-formatting for the entire LLVM source tree.