bcm5719-llvm/clang/test/Format, branch meklort-10.0.1

[clang-format] Proposal for clang-format to give compiler style warnings

2019-10-13T14:51:45+00:00

relanding {D68554} with fixed lit tests, checked on Windows and MacOS llvm-svn: 374720

Revert r374663 "[clang-format] Proposal for clang-format to give compiler style warnings"

2019-10-12T22:58:34+00:00

The test fails on macOS and looks a bit wrong, see comments on the review. Also revert follow-up r374686. llvm-svn: 374688

[clang-format] Proposal for clang-format to give compiler style warnings

2019-10-12T15:36:05+00:00

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 > ^ > ClangFormat.cpp:55:20: warning: code should be clang-formatted [-Wclang-format-violations] > LineRanges("lines", cl::desc(": - format a range of\n" > ^ > ClangFormat.cpp:55:77: warning: code should be clang-formatted [-Wclang-format-violations] > LineRanges("lines", cl::desc(": - 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

Re-land Remove REQUIRES:shell from tests that pass for me on Windows

2019-09-10T20:15:45+00:00

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

Revert Remove REQUIRES:shell from tests that pass for me on Windows

2019-09-10T08:48:33+00:00

This reverts r371478 (git commit a9980f60ce083fa6d5fd03c12c58ca0b293e3d60) llvm-svn: 371497

Remove REQUIRES:shell from tests that pass for me on Windows

2019-09-10T00:50:32+00:00

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

[clang-format][tests] Explicitly specify style in some tests

2019-07-12T15:56:18+00:00

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

[clang-format] Fix bug where -dump-config failed on ObjC header

2018-01-29T17:36:43+00:00

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

[clang] Get rid of "%T" expansions

2017-08-15T19:47:06+00:00

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

clang-format: add an option -verbose to list the files being processed

2017-08-12T15:15:10+00:00

Reviewers: djasper Reviewed By: djasper Subscribers: klimek, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D34824 llvm-svn: 310778