Followup to #136022, this ensures formatting tests are run with an empty
`.clang-format-ignore` in their root directory, to prevent failures if
the file also exists higher in the tree.
This patch adds a lit test to clang format to ensure that the
ClangFormatStyleOptions doc page has been updated appropriately. The
test just runs the automatic update script and diffs the outputs to
ensure they are the same.
With the --force (or -f) option, git-clang-format wipes out input files
excluded by a .clang-format-ignore file if they have unstaged changes.
This patch adds a hidden clang-format option --list-ignored that lists
such excluded files for git-clang-format to filter out.
Fixes#102459.
At the moment clang-format will return exit code 0 on incomplete
results. In scripts it would sometimes be useful if clang-format would
instead fail in those cases, signalling that there was something wrong
with the code being formatted.
---------
Co-authored-by: Björn Schäpers <github@hazardy.de>
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Commit d813af73f70f addressed a regression introduced by commit
3791b3fca6ea
but caused `clang-format -dump-config` to "hang".
This patch reverts changes to ClangFormat.cpp by both commits and
reworks the cleanup.
Fixes#80621.
The code cleanup in #74794 accidentally broke detection of languages by
reading file content from stdin, e.g. via `clang-format -dump-config - <
/path/to/filename`.
This PR adds unit and integration tests to reproduce the issue and adds
a fix.
Fixes: #79023
(42ec976184ac was reverted by 26993f61673e due to a use-after-scope bug.)
Reuse the patterns governing the previous input file being formatted if
the current input file is from the same directory.
This reverts commit 42ec976184acd40436acd7104ad715c60ca3e7ed.
Reason: Broke the sanitizer buildbots. See more information on the
github comment thread at
42ec976184
The test is now properly covered in unit tests, and shouldn't have been
added in the initial commit of D152473.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D152584
After https://reviews.llvm.org/D151954 we've noticed some issues w/
clang-format behavior, as outlined in
https://github.com/llvm/llvm-project/issues/63170.
Valid C/C++ files, that were previously accepted, are now rejected by
clang-format, emitting the message:
"The new replacement overlaps with an existing replacement."
This reverts commit 4b9764959dc4b8783e18747c1742ab164e4bc4ee and
d2627cf88d2553a4c2e850430bdb908a4b7d2e52, which depends on it.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D152473
This adds to the ObjC language guesser a few more common macros used
in ObjC headers. These can help distinguish ObjC headers which
otherwise lack ObjC types from C++ headers.
Contributed by danblakemore.
Tested: New tests included. Ran unit tests with:
```
% cmake -S llvm -B build -G Ninja && \
ninja -C build FormatTests && \
./build/tools/clang/unittests/Format/FormatTests --gtest_filter="*FormatTestObjC*"
(snip)
[----------] 24 tests from FormatTestObjC (265 ms total)
[----------] Global test environment tear-down
[==========] 26 tests from 2 test suites ran. (270 ms total)
[ PASSED ] 26 tests.
```
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D151578
This is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: MatzeB
Differential Revision: https://reviews.llvm.org/D150761
This patch modifies the testcase to use error substitution so it will pass on all platforms.
Reviewed By: fanbo-meng, zibi
Differential Revision: https://reviews.llvm.org/D134034
On z/OS, other error messages are not matched correctly in lit tests.
```
EDC5121I Invalid argument.
EDC5111I Permission denied.
```
This patch adds a lit substitution to fix it.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D95808
Add new option called InsertEmptyLineBeforeAccessModifier. Empty line
before access modifier is inerted if this option is set to true (which
is the default value, because clang-format always inserts empty lines
before access modifiers), otherwise empty lines are removed.
Fixes issue #16518.
Differential Revision: https://reviews.llvm.org/D93846
This overload should be used for better diagnostics when parsing configurations.
Now a failure to parse will list the filename (or <command-line>) instead of just `YAML`.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D93633
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
Currently clang-format starts overriding the default values at index 0
(keeping the existing values) instead of appending or replacing all values.
This patch simply checks the current (IMO surprising) behaviour and does
not attempt to change it.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D86941
Summary:
Related somewhat to {D29039}
On seeing a quote on twitter by @invalidop
> If it's not formatted with clang-format it's a build error.
This made me want to change the way I use clang-format into a tool that could optionally show me where my source code violates clang-format syle.
When I'm making a change to clang-format itself, one thing I like to do to test the change is to ensure I didn't cause a huge wave of changes, what I want to do is simply run this on a known formatted directory and see if any new differences arrive in a manner I'm used to.
This started me thinking that we should allow build systems to run clang-format on a whole tree and emit compiler style warnings about files that fail clang-format in a form that would make them as a warning in most build systems and because those build systems range in their construction I don't think its unreasonable to NOT expect them to have to do the directory searching or parsing the output replacements themselves, but simply transform that into an error code when there are changes required.
I am starting this by suggesing adding a -n or -dry-run command line argument which would emit a warning/error of the form
Support for various common compiler command line argumuments like '-Werror' and '-ferror-limit' could make this very flexible to be integrated into build systems and CI systems.
```
> $ /usr/bin/clang-format --dry-run ClangFormat.cpp -ferror-limit=3 -fcolor-diagnostics
> ClangFormat.cpp:54:29: warning: code should be clang-formatted [-Wclang-format-violations]
> static cl::list<std::string>
> ^
> ClangFormat.cpp:55:20: warning: code should be clang-formatted [-Wclang-format-violations]
> LineRanges("lines", cl::desc("<start line>:<end line> - format a range of\n"
> ^
> ClangFormat.cpp:55:77: warning: code should be clang-formatted [-Wclang-format-violations]
> LineRanges("lines", cl::desc("<start line>:<end line> - format a range of\n"
> ^
```
Reviewers: mitchell-stellar, klimek, owenpan
Reviewed By: klimek
Subscribers: mgorny, cfe-commits
Tags: #clang-format, #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D68554
llvm-svn: 374663
This reverts r371497 (git commit 3d7e9ab7b9f8c53aa41420c54970f0fb421004a2)
Reorder `not` with `env` in these two tests so they pass:
Driver/rewrite-map-in-diagnostics.c
Index/crash-recovery-modules.m.
This will not be necessary after D66531 lands.
llvm-svn: 371552
I see in the history for some of these tests REQUIRES:shell was used as
a way to disable tests on Windows because they are flaky there. I tried
not to re-enable such tests, but it's possible that I missed some and
this will re-enable flaky tests on Windows. If so, we should disable
them with UNSUPPORTED:system-windows and add a comment that they are
flaky there. So far as I can tell, the lit internal shell is capable of
running all of these tests, and we shouldn't use REQUIRES:shell as a
proxy for Windows.
llvm-svn: 371478
Summary: This fixes broken tests when doing an out-of-source build that picks up a random .clang-format on the file system due to the default "file" style.
Reviewers: djasper, klimek, MyDeveloperDay, krasimir
Reviewed By: MyDeveloperDay
Subscribers: lebedev.ri, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61001
llvm-svn: 365909
Summary:
`clang-format -dump-config path/to/file.h` never passed
anything for the Code parameter to clang::format::getStyle().
This meant the logic to guess Objective-C from the contents
of a .h file never worked, because LibFormat didn't have the
code to work with.
With this fix, we now correctly read in the contents of the
file if possible with -dump-config.
I had to update the lit config for test/Format/ because
the default config ignores .h files.
Test Plan: make -j12 check-clang
Reviewers: jolesiak, krasimir
Reviewed By: jolesiak, krasimir
Subscribers: Wizard, klimek, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D42395
llvm-svn: 323668
The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t.
This patch removes %T in clang.
Differential Revision: https://reviews.llvm.org/D36437
llvm-svn: 310950
