In an indirect buffer, buffer-file-name is nil, so check the base buffer
instead. This works fine in direct buffers where buffer-base-buffer returns
nil.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D120408
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
Relevant issue: https://github.com/llvm/llvm-project/issues/52705
When the `DisableFormat` option of `clang-format` is set to `true` and a JSON file is formatted, the ephemeral variable binding that is added to the top-level object is not removed from the formatted file. For example, this JSON:
```
{
"key": "value"
}
```
Is reformatted to:
```
x = {
"key": "value"
}
```
Which is not valid JSON syntax. This fix avoids the addition of this binding when `DisableFormat` is set to `true`, ensuring that it cannot be left behind when formatting is disabled.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D115769Fixes#52705
When running git-clang-format in a pre-commit hook it's very useful to be able to tell git-clang-format to only look at the --staged/--cached files and not the working directory.
Note this patch is a rebase/fork from {D41147 } which is a fork of {D15465 }
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, lodato
Differential Revision: https://reviews.llvm.org/D90996
Co-authored-by: Mark Lodato <lodato@google.com>
Following a change {D111273} to allow git-clang-format to see single lines being removed,
we introduced a regression such that if you are removing a whole file it will
assert in clang-format as its given the -lines=0:0 (lines are 1 based)
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D112056
[git-clang-format][PR46815] Add diffstat functionality
Adding a --diffstat parameter to git-clang-format that essentially uses git diff --stat, i.e. lists the files needing
formatting. This is useful for CI integration or manual usage where one wants to list the files not properly formatted.
I use it for the Suricata project's github action (CI) integration that verifies proper formatting of a pull request
according to project guidelines where it's very helpful to say which files are not properly formatted. I find the list
of files much more useful than e.g. showing the diff in this case using git-clang-format --diff.
An alternative would be to take an additional parameter to diff, e.g. git-clang-format --diff --stat
The goal is not to provide the whole git diff --stat=... parameter functionality, just plain git diff --stat.
Reviewed By: MyDeveloperDay, JakeMerdichAMD
Differential Revision: https://reviews.llvm.org/D84375
This is a bug which gets reported from time to time and we've had multiple attempts to fix it, but don't want to fix it by adding frontEnd to the mix.
This patch aim to find a trivial, but not that sophisticated way of emitting the error without the additional impact of adding libFrontEnd to clang-format.
See {D90121} for analysis of why we don't want those previous attempts
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D111815
If we only delete lines that are outer block statements (if, while, etc),
clang-format-diff.py can't format the statements inside the block statements.
An example to repro:
1. Delete the if statment at line 118 in llvm/lib/CodeGen/Analysis.cpp.
2. Run `git diff -U0 --no-color HEAD^ | clang/tools/clang-format/clang-format-diff.py -i -p1`
It fails to format the statement after if.
Differential Revision: https://reviews.llvm.org/D111273
This change now generates that list, and the change to clang-format allows
us to run clang-format quickly over these files via the list of files.
clang-format.exe -verbose -n --files=./clang/docs/tools/clang-formatted-files.txt
```
Clang-formating 7926 files
Formatting [1/7925] clang/bindings/python/tests/cindex/INPUTS/header1.h
..
Formatting [7925/7925] utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/config.h
```
This is needed because putting all those files on the command line is too
long, and invoking 7900+ clang-formats is much slower (too slow to be honest)
Using this method it takes on 7.5 minutes (on my machine) to run
`clang-format -n` over all of the files (7925), this should result in us
testing any change quickly and easily.
We should be able to use rerunning this list to ensure that we don't regress
clang-format over a large code base, but also use it to ensure none of the
previous files which were 100% clang-formatted remain so.
(which the LLVM premerge checks should be enforcing)
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D111000
When specifying the alignment direction on the command line ensure
we set up the default ordering.
Fix spelling mistakes in the command-line argument
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D110359
Developers these days seem to argue over east vs west const like they used to argue over tabs vs whitespace or the various bracing style. These previous arguments were mainly eliminated with tools like `clang-format` that allowed those rules to become part of your style guide. Anyone who has been using clang-format in a large team over the last couple of years knows that we don't have those religious arguments any more, and code reviews are more productive.
https://www.youtube.com/watch?v=fv--IKZFVO8https://mariusbancila.ro/blog/2018/11/23/join-the-east-const-revolution/https://www.youtube.com/watch?v=z6s6bacI424
The purpose of this revision is to try to do the same for the East/West const discussion. Move the debate into the style guide and leave it there!
In addition to the new `ConstStyle: Right` or `ConstStyle: Left` there is an additional command-line argument `--const-style=left/right` which would allow an individual developer to switch the source back and forth to their own style for editing, and back to the committed style before commit. (you could imagine an IDE might offer such a switch)
The revision works by implementing a separate pass of the Annotated lines much like the SortIncludes and then create replacements for constant type declarations.
Differential Revision: https://reviews.llvm.org/D69764
I find as I develop I'm moving between many different languages C++,C#,JavaScript all the time. As I move between the file types I like to keep `clang-format` as my formatting tool of choice. (hence why I initially added C# support in {D58404}) I know those other languages have their own tools but I have to learn them all, and I have to work out how to configure them, and they may or may not have integration into my IDE or my source code integration.
I am increasingly finding that I'm editing additional JSON files as part of my daily work and my editor and git commit hooks are just not setup to go and run [[ https://stedolan.github.io/jq/ | jq ]], So I tend to go to [[ https://jsonformatter.curiousconcept.com/ | JSON Formatter ]] and copy and paste back and forth. To get nicely formatted JSON. This is a painful process and I'd like a new one that causes me much less friction.
This has come up from time to time:
{D10543}
https://stackoverflow.com/questions/35856565/clang-format-a-json-filehttps://bugs.llvm.org/show_bug.cgi?id=18699
I would like to stop having to do that and have formatting JSON as a first class clang-format support `Language` (even if it has minimal style settings at present).
This revision adds support for formatting JSON using the inbuilt JSON serialization library of LLVM, With limited control at present only over the indentation level
This adds an additional Language into the .clang-format file to separate the settings from your other supported languages.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D93528
This fixes PR46992.
Git stores symlinks as text files and we should not format them even if
they have one of the requested extensions.
(Move the call to `cd_to_toplevel()` up a few lines so we can also print
the skipped symlinks during verbose output.)
Differential Revision: https://reviews.llvm.org/D101878
Different distributions have different strategies migrating the `python` symlink. Debian and its derivatives provide `python-is-python2` and `python-is-python3`. If neither is installed, the user gets no `/usr/bin/python`. The clang-format-diff script and consequently `arc diff` can thus fail with a python not found error. Since we require python greater than 3.6 as part of llvm prerequisites (https://llvm.org/docs/GettingStarted.html#software), let's go ahead and update this shebang.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D100968
Previously if we couldn't run the clang-format command
for some reason, you'd get an unhelpful error message:
```
OSError: [Errno 2] No such file or directory
```
Which doesn't tell you what was happening to cause this.
Catch the error and add the command we were attempting to run:
```
RuntimeError: Failed to run "<...>/clang-food <...>" - No such file or directory"
RuntimeError: Failed to run "<...>/clang-format <...>" - Permission denied"
```
Reviewed By: krasimir
Differential Revision: https://reviews.llvm.org/D98032
Adds an option to [clang-format] which sorts headers in an alphabetical manner using case only for tie-breakers. The options is off by default in favor of the current ASCIIbetical sorting style.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D95017
As noted in https://reviews.llvm.org/D86137#2460135 parsing of
the clang-format parameter -Wno-error=unknown fails.
This currently is done by having `-Wno-error=unknown` as an option.
In this patch this is changed to make `-Wno-error=` parse an enum into a bit set.
This way the parsing is fixed and also we can possibly add new options easily.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D93459
Clang supports compiling CUDA source files,
CUDA header files may contain CUDA specific code
that is why they have special extension, which
can be recognized by nvcc (CUDA compiler driver)
as CUDA source file.
Format them by default as well.
Reviewed By: MyDeveloperDay
Patch By: tomilov
Differential Revision: https://reviews.llvm.org/D90780
Contributed by dmikis (Kirill Dmitrenko)!
Otherwise problems like trying to format readonly file in-place led to crashes.
I've added reviewers by looking at `git blame` and other reviews to the changed file, so may have missed someone.
Reviewed By: krasimir
Differential Revision: https://reviews.llvm.org/D90121
`SourceManager::createFileID` asserts that the given `FileEntry` is not
null, so remove the logic that passed in `nullptr`. Since we just added
the file to an in-memory FS via an API that cannot fail, use
`llvm_unreachable` on the error path. Didn't use an `assert` since it
seems cleaner semantically to check the error (and better,
hypothetically, for updating the API to use `Expected` instead of
`ErrorOr`).
I noticed this incidentally while auditing calls to `createFileID`.
Currently newer clang-format options cannot be included in .clang-format files, if not all users can be forced to use an updated version.
This patch tries to solve this by adding an option to clang-format, enabling to ignore unknown (newer) options.
Differential Revision: https://reviews.llvm.org/D86137
Quiet mode is very useful for scripting, when only the diff format output is
required, or no output if not formatting is needed.
In case of no modified files, git-clang-format will output to screen even though
the quiet mode enabled.
This patch changes this behavior, so if quiet flag passes in - no output will be
available, even if no modified files exists.
Differential Revision: https://reviews.llvm.org/D85485
Summary: If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewers: wallace, clayborg
Reviewed By: wallace, clayborg
Subscribers: cfe-commits, aprantl, lldb-commits
Tags: #lldb, #clang
Differential Revision: https://reviews.llvm.org/D83731
Summary:
https://bugs.llvm.org/show_bug.cgi?id=46043
Git's config is generally of the format 'key=val', but a setting
'key=true' can be written as just 'key'. The git-clang-format script
expects a value and crashes in this case; this change handles implicit
'true' values in the script.
Reviewers: MyDeveloperDay, krasimir, sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80486
Summary:
Add --relative to the suggested git-diff one liner. If the user does not
pass this argument, then git will produce a diff with the path relative
to the repository root. If the user's working directory is not the
repository root, then clang-format will complain that the file is not
found. The --relative argument makes git produce a diff with the files
relative to the working directory.
Add note to doc string to warn users about the fact that filenames
embedded in the diff are used as-is with no attempts to "do what they
mean, not what they say"
Reviewers: djasper, alexfh, efriedma, klimek, thakis
Reviewed By: efriedma
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79054
Summary: Testing for None should use the 'is' operator.
Reviewed By: MyDeveloperDay
Patch By: eagleoflqj
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D77974
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:
Review comments in {D69854} recommended a simpler approach of creating the SMDiagnostics to remove much of the complexity. (thanks @thakis)
@vlad.tsyrklevich I've rebuilt on both Windows and Linux (running Linux with Address and Undefined sanitizers) over the clang code base
Reviewers: thakis, klimek, mitchell-stellar, vlad.tsyrklevich
Reviewed By: thakis
Subscribers: cfe-commits, thakis, vlad.tsyrklevich
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D69921
Summary:
By additional regex match, grouping of main include can be enabled in files that are not normally considered as a C/C++ source code.
For example, this might be useful in templated code, where template implementations are being held in *Impl.hpp files.
On the occassion, 'assume-filename' option description was reworded as it was misleading. It has nothing to do with `style=file` option and it does not influence sourced style filename.
Reviewers: rsmith, ioeric, krasimir, sylvestre.ledru, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch by: furdyna
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67750
Summary:
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
owenca