Summary: Python 3.8 introduces a SyntaxWarning about string comparisons with 'is'. This commit updates the string comparison in clang-format.py that is done with 'is not' to '!='. This should not break compatibility with older python versions (tested 3.4.9, 2.7.17, 2.7.5, 3.8.0).
Reviewers: MyDeveloperDay, klimek, llvm-commits, cfe-commits
Reviewed By: MyDeveloperDay, klimek
Patch By: pseyfert
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D70664
Summary:
The current clang-format.py does not handle trailing newlines at the end of a file correctly.
Trailing empty lines get removed except one.
As far as I understand this is because clang-format gets fed from stdin and writes to stdout when called from clang-format.py.
In a "normal" file (with no trailing empty lines) the string that gets passed to clang-format does not contain a trailing '\n' after the '\n'.join from python.
The clang-format binary does not add a trailing newline to input from stdin, but (if there are multiple trailing '\n', all except one get removed).
When reading back this means that we see in python from a "normal" file a string with no trailing '\n'. From a file with (potentially multiple) empty line(s) at the end, we get a string with one trailing '\n' back in python. In the former case all is fine, in the latter case split('\n') makes one empty line at the end of the file out of the clang-format output. Desired would be instead that the **file** ends with a newline, but not with an empty line.
For the case that a user specifies a range to format (and wants to keep trailing empty lines) I did **not** try to fix this by simply removing all trailing newlines from the clang-format output. Instead, I add a '\n' to the unformatted file content (i.e. newline-terminate what is passed to clang-format) and then strip off the last newline from the output (which itself is now for sure the newline termination of the clang-format output).
(Should this get approved, I'll need someone to help me land this.)
Reviewers: klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Patch By: pseyfert
Subscribers: cfe-commits, llvm-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D70864
update trailing newline treatment in clang-format.py
Summary:
D23319 introduced python3 compatibility to clang-format.py, this is however not reflected by the documentation in the comments at the beginning of the file, which show how to use the script with python2 in .vimrc. While the actual mapping a user might want to use may well differ from my suggestion, I think it's nice to show the python2 and python3 version, such that a user can pick from the suggestions instead of googeling the python3 replacement for `:pyf` which they might not be familiar with.
EDIT: picking reviewers according to https://llvm.org/docs/Phabricator.html#finding-potential-reviewers
Reviewers: klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: ilya-biryukov, cfe-commits, llvm-commits, ychen
Patch By: pseyfert
Tags: #clang-tools-extra, #llvm, #clang
Differential Revision: https://reviews.llvm.org/D38446
Summary:
This allows downstream customizations to the default style to work without
needing to also modify the editor integrations.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49719
llvm-svn: 360996
Summary:
This patch fixes a regression after https://reviews.llvm.org/rL305665,
which updates the structure of the `lines` variable.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37011
llvm-svn: 311456
With this patch, one can configure a BufWrite hook that will make the
clang-format integration compute a diff of the current buffer with the file
that's on disk and format all changed lines. This should create a
zero-overhead auto-format solution that doesn't require the file to
already be clang-format clean to avoid spurious diffs.
Review: https://reviews.llvm.org/D32429
llvm-svn: 305665
The entries in vim.current.buffer appear to be decoded strings, which
means that python3 won't allow invoking 'decode' on them. Keep the old
behavior when running under python2, but skip the error-inducing decode
step with python3..
llvm-svn: 289308
clang-format.py currently seems to treat vim.current.buf as ascii-encoded data,
which leads to an UnicodeDecodeError when trying to format any text containing
non-ascii characters:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File ".../tools/clang/tools/clang-format/clang-format.py", line 110, in <module>
main()
File ".../tools/clang/tools/clang-format/clang-format.py", line 87, in main
stdout, stderr = p.communicate(input=text.encode(encoding))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 3996: ordinal not in range(128)
llvm-svn: 284988
clang-format.py previously only worked in vim compiled against python2.
This patch adds the necessary syntax changes to make this work with vim
linked against python3, which is now shipped by default for at least Ubuntu16 and Arch.
Differential Revision: https://reviews.llvm.org/D23319
Subscribers: cfe-commits
llvm-svn: 280240
This has seen quite some usage and I am not aware of any issues. Also
add a style option to enable/disable include sorting. The existing
command line flag can from now on be used to override whatever is set
in the style.
llvm-svn: 253202
To implement this nicely, add a function that merges two sets of
replacements that are meant to be done in sequence. This functionality
will also be useful for other applications, e.g. formatting the result
of clang-tidy fixes.
llvm-svn: 248367
When clang-format encounters a syntax error, it will not format that
line; we're now using the same mechanism we're already using in emacs to
show a helpful error message to the user.
llvm-svn: 238823
With this patch, clang-format.py will search and use existing .clang-format
file if there is one and fallback to the specific format style if
not. It should cover the projects which don't have .clang-format
files in their source. As the option fallback-style is available in
clang 3.5 or later, it is safe to use.
Patch by "Chilledheart" (http://reviews.llvm.org/D8489).
llvm-svn: 235080
If g:clang_format_path is set in the vimrc, that path will take precedence over
the hard coded path (which is reliant on the PATH environment variable). This
provides an easy mechanism for switching the selected clang-format binary during
development.
llvm-svn: 221108
Improve the documentation for vim integration of clang-format. Prefer the use
of <c-o> to do the normal mode command execution to avoid side-effects of the
escape and re-insertion (cursor movement). Tweak the macros to use a double
return to avoid having to manually return control to the editor from the
subprocess.
llvm-svn: 220685
With -style=file, clang-format now starts to search for a .clang-format
file starting at the file given with -assume-filename if it reads from
stdin. Otherwise, it would start searching from the current directory,
which is not helpful for editor integrations.
Also changed vim, emacs and sublime integrations to actually make use of
this flag.
This fixes llvm.org/PR17072.
llvm-svn: 190691
Dotfiles are impractical on Windows. This makes clang-format search
for the style configuration file as '_clang-format' in addition to
the usual '.clang-format'. This is similar to how VIM searches for
'_vimrc' on Windows.
Differential Revision: http://llvm-reviews.chandlerc.com/D1629
llvm-svn: 190413
fallback syntax used when we fail to find a '.clang-format' file. Adjust
variable names appropriately.
Update the editor integration pieces that specify a '-style' option to
specify it as '-style=file'. I left the functionality in place because
even if the preferred method is to use '.clang-format' files, this way
if someone needs to clobber the style in their editor we show how to do
so in these examples.
Also check in a '.clang-format' file for Clang to ensure that separate
checkouts and builds of Clang from LLVM can still get the nice
formatting. =] This unfortunately required nuking the test for the
absence of a '.clang-format' file as now the directory happening to be
under your clang source tree will cause there to always be a file. ;]
llvm-svn: 189741
After the first operation, the buffer contents has changed and thus all
other operations would be invalid. Executing the operations in reversed
order should fix this.
llvm-svn: 186840
With this fix, only changed regions will be replaced in vim's buffer.
Thereby, marks should mostly be left intact. Furthermore, this is a
better fix for the performance problem in conjunction with
'foldmethod=syntax' (see r186660).
llvm-svn: 186789
The previous line-by-line replacement causes vim to take a long time if
the foldmethod is set to 'syntax'. This should significantly improve
performance in that case.
llvm-svn: 186660
With this patch, clang-format will try to keep the cursor at the
original code position in editor integrations (implemented for emacs and
vim). This means, after formatting, clang-format will try to keep the
cursor on the same character of the same token.
llvm-svn: 182373
This adds an emacs editor integration (thanks to Ami Fischman). Also
pulls out the style into a variable for the vi integration and just
uses clang-formats defaults style in clang-format-diff.py.
llvm-svn: 179098
Sam McCall