summaryrefslogtreecommitdiffstats
path: root/clang/unittests/Format
Commit message (Collapse)AuthorAgeFilesLines
...
* [clang-format] Fix the bug that joins template closer and > or >>Owen Pan2019-08-161-1/+4
| | | | | | | | | | Also fixes a buggy test case. See PR42404 Differential Revision: https://reviews.llvm.org/D66332 llvm-svn: 369157
* [clang-format] Expand AllowShortBlocksOnASingleLine for WebKitOwen Pan2019-08-111-9/+30
| | | | | | | | See PR40840 Differential Revision: https://reviews.llvm.org/D66059 llvm-svn: 368539
* [clang-format] Add SpaceInEmptyBlock option for WebKitOwen Pan2019-08-101-0/+6
| | | | | | | | See PR40840 Differential Revision: https://reviews.llvm.org/D65925 llvm-svn: 368507
* [clang-format] fix crash involving invalid preprocessor lineKrasimir Georgiev2019-08-081-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This (invalid) fragment is crashing clang-format: ``` #if 1 int x; #elif int y; #endif ``` The reason being that the parser expects a token after `#elif`, and the subsequent parsing of the next line does not check if `CurrentToken` is null. Reviewers: gribozavr Reviewed By: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65940 llvm-svn: 368280
* [clang-format] Fix a bug that doesn't break braces before unions for AllmanOwen Pan2019-08-021-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D65631 llvm-svn: 367648
* clang-format: Support `if CONSTEXPR` if CONSTEXPR is a macro.Nico Weber2019-07-271-0/+89
| | | | | | | | | | | | | | | | | | | | | | This is like r305666 (which added support for `if constexpr`) except that it allows a macro name after the if. This is slightly tricky for two reasons: 1. r305666 didn't add test coverage for all cases where it added a kw_constexpr, so I had to figure out what all the added cases were for. I now added tests for all `if constexpr` bits that didn't have tests. (This took a while, see e.g. https://reviews.llvm.org/D65223) 2. Parsing `if <ident> (` as an if means that `#if defined(` and `#if __has_include(` parse as ifs too. Add some special-case code to prevent this from happening where it's incorrect. Fixes PR39248. Differential Revision: https://reviews.llvm.org/D65227 llvm-svn: 367167
* clang-format: Add another test like r366926Nico Weber2019-07-241-0/+1
| | | | llvm-svn: 366929
* clang-format: Add a test that shows that some code I thought was dead is ↵Nico Weber2019-07-241-0/+1
| | | | | | not dead. llvm-svn: 366926
* clang-format: Fix namespace end comments for namespaces with attributes and ↵Nico Weber2019-07-232-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | macros. Fixes PR39247. While here, also make C++20 `namespace A::inline B::inline C` nested inline namespaced definitions work. Before: #define DEPRECATE_WOOF [[deprecated("meow")]] namespace DEPRECATE_WOOF woof { void f() {} } // namespace DEPRECATE_WOOFwoof namespace [[deprecated("meow")]] woof { void f() {} } // namespace [[deprecated("meow")]]woof namespace woof::inline bark { void f() {} } // namespace woof::inlinebark Now: #define DEPRECATE_WOOF [[deprecated("meow")]] namespace DEPRECATE_WOOF woof { void f() {} } // namespace woof namespace [[deprecated("meow")]] woof { void f() {} } // namespace woof namespace woof::inline bark { void f() {} } // namespace woof::inline bark (In addition to the fixed namespace end comments, also note the correct indent of the namespace contents.) Differential Revision: https://reviews.llvm.org/D65125 llvm-svn: 366831
* Adds support for formatting NS_CLOSED_ENUM and CF_CLOSED_ENUM alongside ↵Ben Hamilton2019-07-222-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NS_ENUM and CF_ENUM. Summary: Addresses the formatting of NS_CLOSED_ENUM and CF_CLOSED_ENUM, introduced in Swift 5. Before: ``` typedef NS_CLOSED_ENUM(NSInteger, Foo){FooValueOne = 1, FooValueTwo, FooValueThree}; ``` After: ``` typedef NS_CLOSED_ENUM(NSInteger, Foo) { FooValueOne = 1, FooValueTwo, FooValueThree }; ``` Contributed by heijink. Reviewers: benhamilton, krasimir Reviewed By: benhamilton Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65012 llvm-svn: 366719
* [Format/ObjC] Avoid breaking between unary operators and operandsBen Hamilton2019-07-191-0/+12
| | | | | | | | | | | | | | | | | | | | Summary: Test Plan: New tests added. Ran tests with: % ninja FormatTests && ./tools/clang/unittests/Format/FormatTests Confirmed tests failed before change and passed after change. Reviewers: krasimir, djasper, sammccall, klimek Reviewed By: sammccall Subscribers: klimek, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64775 llvm-svn: 366592
* [clang-format] Don't detect call to ObjC class method as C++11 attribute ↵Ben Hamilton2019-07-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | specifier Summary: Previously, clang-format detected something like the following as a C++11 attribute specifier. @[[NSArray class]] instead of an array with an Objective-C method call inside. In general, when the attribute specifier checking runs, if it sees 2 identifiers in a row, it decides that the square brackets represent an Objective-C method call. However, here, `class` is tokenized as a keyword instead of an identifier, so this check fails. To fix this, the attribute specifier first checks whether the first square bracket has an "@" before it. If it does, then that square bracket is not the start of a attribute specifier because it is an Objective-C array literal. (The assumption is that @[[.*]] is not valid C/C++.) Contributed by rkgibson2. Reviewers: benhamilton Reviewed By: benhamilton Subscribers: aaron.ballman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64632 llvm-svn: 366267
* cmake: Add CLANG_LINK_CLANG_DYLIB optionTom Stellard2019-07-031-1/+1
| | | | | | | | | | | | | | | | Summary: Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against libclang_shared.so instead of the individual component libraries. Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru Subscribers: arphaman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63503 llvm-svn: 365092
* clang-format: Add new style option AlignConsecutiveMacrosSam McCall2019-07-021-0/+98
| | | | | | | | | | | | | | | | | | | | | | This option behaves similarly to AlignConsecutiveDeclarations and AlignConsecutiveAssignments, aligning the assignment of C/C++ preprocessor macros on consecutive lines. I've worked in many projects (embedded, mostly) where header files full of large, well-aligned "#define" blocks are a common pattern. We normally avoid using clang-format on these files, since it ruins any existing alignment in said blocks. This style option will align "simple" PP macros (no parameters) and PP macros with parameter lists on consecutive lines. Related Bugzilla entry (thanks mcuddie): https://llvm.org/bugs/show_bug.cgi?id=20637 Patch by Nick Renieris (VelocityRa)! Differential Revision: https://reviews.llvm.org/D28462 llvm-svn: 364938
* clang-format: better handle namespace macrosFrancois Ferrand2019-06-062-0/+384
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Other macros are used to declare namespaces, and should thus be handled similarly. This is the case for crpcut's TESTSUITE macro, or for unittest-cpp's SUITE macro: TESTSUITE(Foo) { TEST(MyFirstTest) { assert(0); } } // TESTSUITE(Foo) This patch deals with this cases by introducing a new option to specify lists of namespace macros. Internally, it re-uses the system already in place for foreach and statement macros, to ensure there is no impact on performance. Reviewers: krasimir, djasper, klimek Reviewed By: klimek Subscribers: acoomans, cfe-commits, klimek Tags: #clang Differential Revision: https://reviews.llvm.org/D37813 llvm-svn: 362740
* [clang-format] Allow configuring list of function-like macros that resolve ↵Francois Ferrand2019-05-291-0/+29
| | | | | | | | | | | | | | | | | | | | | | | to a type Summary: Adds a `TypenameMacros` configuration option that causes certain identifiers to be handled in a way similar to `typeof()`. This is enough to: - Prevent misinterpreting declarations of pointers to such types as expressions (`STACK_OF(int) * foo` -> `STACK_OF(int) *foo`), - Avoid surprising line breaks in variable/struct field declarations (`STACK_OF(int)\nfoo;` -> `STACK_OF(int) foo;`, see https://bugs.llvm.org/show_bug.cgi?id=30353). Reviewers: Typz, krasimir, djasper Reviewed By: Typz Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57184 llvm-svn: 361986
* [NFC] clang-format: Use LLVM style in NamespaceEndCommentsFixerTestFrancois Ferrand2019-05-291-148/+149
| | | | | | | | | | As pointed out in https://reviews.llvm.org/D37813#inline-555026, the code which is formatted does not match LLVM formatting style. Technically this is not a problem since these tests bypass most of the formatter, but it can be misleading. llvm-svn: 361984
* Revert "Revert "[clang-format] Keep protobuf "package" statement on one line""Krasimir Georgiev2019-05-101-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Summary: Top-level "package" and "import" statements should generally be kept on one line, for all languages. ---- This reverts commit rL356912. The regression from rL356835 was fixed via rC358275. Reviewers: krasimir, sammccall, MyDeveloperDay, xinz, dchai, klimek Reviewed By: krasimir, xinz, dchai Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60661 llvm-svn: 360411
* [clang-format] Fix bug in block comment reflow that joins * and /Owen Pan2019-05-031-0/+18
| | | | | | | | Fixes PR41213 Differential Revision: https://reviews.llvm.org/D61276 llvm-svn: 359943
* [clang-format] Fix a bug in AlignConsecutiveDeclarations.Owen Pan2019-05-011-0/+7
| | | | | | | | Fixes PR37175 Differential Revision: https://reviews.llvm.org/D61222 llvm-svn: 359711
* [clang-format] Fix bug that misses some function-like macro usagesOwen Pan2019-05-011-0/+6
| | | | | | | | Fixes PR41483 Differential Revision: https://reviews.llvm.org/D61297 llvm-svn: 359687
* [clang-format] Fix bug in reflow of block comments containing CR/LFOwen Pan2019-04-231-0/+6
| | | | | | | | Fix PR36119 Differential Revision: https://reviews.llvm.org/D60996 llvm-svn: 359029
* [clang-format] Fix incorrect formatting of keyword macro definitionOwen Pan2019-04-181-0/+6
| | | | | | | | See PR39719 Differential Revision: https://reviews.llvm.org/D60853 llvm-svn: 358710
* [clang-format] Fix indent of trailing raw string param after newlineKrasimir Georgiev2019-04-181-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently clang-format uses ContinuationIndent to indent the contents of a raw string literal that is the last parameter of the function call. This is to achieve formatting similar to trailing: ``` f(1, 2, R"pb( x: y)pb"); ``` However this had the unfortunate consequence of producing format like this: ``` fffffff(1, 2, R"pb( a: b )pb"); ``` This patch makes clang-format consider indenting a trailing raw string param after a newline based off the start of the format delimiter, producing: ``` fffffff(1, 2, R"pb( a: b )pb"); ``` Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60558 llvm-svn: 358689
* [clang-format] Fix -Wconversion-null warning in GCCReuben Thomas2019-04-151-6/+1
| | | | | | | | | | | | GCC -Wconversion-null warning appeared after 9a63380260860b657b72f07c4f0e61e382ab934a. There was a similar problem already in the past: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20131230/096230.html Patch committed on behalf of @dendibakh Differential Revision: https://reviews.llvm.org/D60726 llvm-svn: 358441
* [clang-format] [PR41170] Break after return type ignored with certain ↵Paul Hoad2019-04-151-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | comments positions Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=41170 The AlwaysBreakAfterReturn type setting can go wrong if the line ends with a comment ``` void foo() /* comment */ ``` or ``` void foo() // comment ``` It will incorrectly see such functions as Declarations and not Definitions The following code addresses this by looking for function which end with `; <comment>` rather than just `;` or `<comment>` Reviewers: klimek, djasper, reuk, russellmcc, owenpan, sammccall Reviewed By: owenpan Subscribers: lebedev.ri, cfe-commits, sammccall Tags: #clang Differential Revision: https://reviews.llvm.org/D60363 llvm-svn: 358375
* [clang-format] Use SpacesBeforeTrailingComments for "option" directiveKrasimir Georgiev2019-04-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: AnnotatingParser::next() is needed to implicitly set TT_BlockComment versus TT_LineComment. On most other paths through AnnotatingParser::parseLine(), all tokens are consumed to achieve that. This change updates one place where this wasn't done. Contributed by @dchai! Reviewers: krasimir Reviewed By: krasimir Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60541 llvm-svn: 358275
* [clang-format] Add AfterCaseLabel to BraceWrappingOwen Pan2019-04-081-14/+36
| | | | | | | | Fixes PR38686 > llvm-svn: 52527 llvm-svn: 357957
* [clang-format] Optionally insert a space after unary ! operatorReuben Thomas2019-04-081-0/+17
| | | | llvm-svn: 357908
* [clang-format] Fix bug https://bugs.llvm.org/show_bug.cgi?id=41413Owen Pan2019-04-071-0/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D60374 llvm-svn: 357877
* [clang-format] Fix Bug 41407Owen Pan2019-04-061-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D60359 llvm-svn: 357851
* [clang-format] BreakAfterReturnType ignored on functions with numeric ↵Paul Hoad2019-04-061-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | template parameters Summary: Addresses PR40696 - https://bugs.llvm.org/show_bug.cgi?id=40696 The BreakAfterReturnType didn't work if it had a single arguments which was a template with an integer template parameter ``` int foo(A<8> a) { return a; } ``` When run with the Mozilla style. would not break after the `int` ``` int TestFn(A<8> a) { return a; } ``` This revision resolves this issue by allowing numeric constants to be considered function parameters if if seen inside `<>` Reviewers: djasper, klimek, JonasToth, krasimir, reuk, alexfh Reviewed By: klimek Subscribers: cfe-commits, llvm-commits Tags: #clang-tools-extra Differential Revision: https://reviews.llvm.org/D59309 llvm-svn: 357837
* [clang-format] Preserve include blocks in ObjC Google styleKrasimir Georgiev2019-04-041-0/+12
| | | | | | | | | | | | | | | | | | Summary: r357567 started to regroup include block for Google style; it was meant to apply only for C++. This patch reverts this for ObjC. Reviewers: ioeric Reviewed By: ioeric Subscribers: thakis, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60263 llvm-svn: 357695
* [clang-format] Do not emit replacements while regrouping if Cpp includes are OKKrasimir Georgiev2019-04-031-9/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently clang-format would always emit a replacement for multi-block #include sections if `IBS_Regroup`, even if the sections are correct: ``` % cat ~/test.h #include <a.h> #include "b.h" % bin/clang-format --output-replacements-xml -style=google ~/test.h <?xml version='1.0'?> <replacements xml:space='preserve' incomplete_format='false'> <replacement offset='0' length='30'>#include &lt;a.h>&#10;&#10;#include "b.h"</replacement> </replacements> % ``` This change makes clang-format not emit replacements in this case. The logic is similar to the one implemented for Java in r354452. Reviewers: ioeric Reviewed By: ioeric Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60199 llvm-svn: 357599
* [clang-format] Regroup #includes into blocks for Google styleEric Liu2019-04-032-3/+15
| | | | | | | | | | | | | | | | | Summary: Regrouping #includes in blocks separated by blank lines when sorting C++ #include headers was implemented recently, and it has been preferred in Google's C++ style guide: https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes Reviewers: sammccall, klimek Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60116 llvm-svn: 357567
* [clang-format] [PR41187] moves Java import statements to the wrong location ↵Paul Hoad2019-03-301-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | if code contains statements that start with the word import Summary: Import sorting of java file, incorrectly move import statement to after a function beginning with the word import. Make 1 character change to regular expression to ensure there is always at least one space/tab after the word import Previously clang-format --style="LLVM" would format ``` import X; class C { void m() { importFile(); } } ``` as ``` class C { void m() { importFile(); import X; } } ``` Reviewers: djasper, klimek, reuk, JonasToth Reviewed By: klimek Subscribers: cfe-commits Tags: #clang-tools-extra Differential Revision: https://reviews.llvm.org/D59684 llvm-svn: 357345
* [clang-format]: Add NonEmptyParentheses spacing optionReuben Thomas2019-03-301-0/+56
| | | | | | | | | | | | | This patch aims to add support for the following rules from the JUCE coding standards: - Always put a space before an open parenthesis that contains text - e.g. foo (123); - Never put a space before an empty pair of open/close parenthesis - e.g. foo(); Patch by Reuben Thomas Differential Revision: https://reviews.llvm.org/D55170 llvm-svn: 357344
* [clang-format] Add style option AllowShortLambdasOnASingleLineRonald Wampler2019-03-261-0/+37
| | | | | | | | | | | | | | | | | Summary: This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas. Reviewers: djasper, klimek Reviewed By: klimek Subscribers: MyDeveloperDay, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57687 llvm-svn: 357027
* [clang-format] Refine structured binding detectionKrasimir Georgiev2019-03-251-0/+24
| | | | | | | | | | | | | | | | | | | | | Summary: Revision r356575 had the unfortunate consequence that now clang-format never detects an ObjC call expression after `&&`. This patch tries harder to distinguish between C++17 structured bindings and ObjC call expressions and adds a few regression tests. Reviewers: klimek Reviewed By: klimek Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59774 llvm-svn: 356928
* Revert "[clang-format] Keep protobuf "package" statement on one line"Haojian Wu2019-03-251-6/+0
| | | | | | | | | | | | | This reverts commit r356835. This patch causes a regression, see the test below: verifyFormat("// Detached comment\n\n" "// Leading comment\n" "syntax = \"proto2\"; // trailing comment\n\n" "// in foo.bar package\n" "package foo.bar; // foo.bar package\n"); llvm-svn: 356912
* [clang-format] Keep protobuf "package" statement on one linePaul Hoad2019-03-231-0/+6
| | | | | | | | | | | | | | | | | | | | Summary: Top-level "package" and "import" statements should generally be kept on one line, for all languages. Reviewers: sammccall, krasimir, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: MyDeveloperDay, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59627 Patch By: dchai (Donald Chai) llvm-svn: 356835
* Clang-format: add finer-grained options for putting all arguments on one linePaul Hoad2019-03-231-3/+196
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add two new options, AllowAllArgumentsOnNextLine and AllowAllConstructorInitializersOnNextLine. These mirror the existing AllowAllParametersOfDeclarationOnNextLine and allow me to support an internal style guide where I work. I think this would be generally useful, some have asked for it on stackoverflow: https://stackoverflow.com/questions/30057534/clang-format-binpackarguments-not-working-as-expected https://stackoverflow.com/questions/38635106/clang-format-how-to-prevent-all-function-arguments-on-next-line Reviewers: djasper, krasimir, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: jkorous, MyDeveloperDay, aol-nnov, lebedev.ri, uohcsemaj, cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D40988 Patch By: russellmcc (Russell McClellan) llvm-svn: 356834
* [clang-format] correctly format protobuf fields named "enum".Paul Hoad2019-03-231-0/+6
| | | | | | | | | | | | | | | | | | Summary: Similar to TypeScript, "enum" is not a reserved word. Reviewers: krasimir, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: MyDeveloperDay, cfe-commits Tags: #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D59629 Patch by: dchai (Donald Chai) llvm-svn: 356833
* [clang-format] Add basic support for formatting C# filesPaul Hoad2019-03-212-0/+185
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [clang-format] BeforeHash added to IndentPPDirectivesPaul Hoad2019-03-201-16/+115
| | | | | | | | | | | | | | | | | | Summary: The option BeforeHash added to IndentPPDirectives. Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019 Reviewers: djasper, klimek, krasimir, sammccall, mprobst, Nicola, MyDeveloperDay Reviewed By: klimek, MyDeveloperDay Subscribers: kadircet, MyDeveloperDay, mnussbaum, geleji, ufna, cfe-commits Patch by to-mix. Differential Revision: https://reviews.llvm.org/D52150 llvm-svn: 356613
* [clang-format] structured binding in range for detected as Objective CPaul Hoad2019-03-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++ Reported by: https://twitter.com/mattgodbolt/status/1096188576503644160 $ clang-format.exe test.h Configuration file(s) do(es) not support Objective-C: C:\clang\build\.clang-format --- test.h -- ``` std::vector<std::pair<std::string,std::string>> C; void foo() { for (auto && [A,B] : C) { std::string D = A + B; } } ``` The following code fixes this issue of incorrect detection Reviewers: djasper, klimek, JonasToth, reuk Reviewed By: klimek Subscribers: cfe-commits Tags: #clang-tools-extra Differential Revision: https://reviews.llvm.org/D59546 llvm-svn: 356575
* [clang-format] [JS] handle private members.Martin Probst2019-03-191-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Addresses PR40999 https://bugs.llvm.org/show_bug.cgi?id=40999 Private fields and methods in JavaScript would get incorrectly indented (it sees them as preprocessor directives and hence left aligns them) In this revision `#identifier` tokens `tok::hash->tok::identifier` are merged into a single new token `tok::identifier` with the `#` contained inside the TokenText. Before: ``` class Example { pub = 1; static pub2 = "foo"; static #priv2 = "bar"; method() { this.#priv = 5; } static staticMethod() { switch (this.#priv) { case '1': break; } } this.#privateMethod(); // infinite loop } static #staticPrivateMethod() {} } ``` After this fix the code will be correctly indented ``` class Example { pub = 1; #priv = 2; static pub2 = "foo"; static #priv2 = "bar"; method() { this.#priv = 5; } static staticMethod() { switch (this.#priv) { case '1': #priv = 3; break; } } #privateMethod() { this.#privateMethod(); // infinite loop } static #staticPrivateMethod() {} } ``` NOTE: There might be some JavaScript code out there which uses the C processor to preprocess .js files http://www.nongnu.org/espresso/js-cpp.html. It's not clear how this revision or even private fields and methods would interact. Patch originally by MyDeveloperDays (thanks!). llvm-svn: 356449
* [clang-format] [JS] Don't break between template string and tagMartin Probst2019-03-191-0/+6
| | | | | | | | | | | | | | | | | | | Before: const x = veryLongIdentifier `hello`; After: const x = veryLongIdentifier`hello`; While it's allowed to have the template string and tag identifier separated by a line break, currently the clang-format output is not stable when a break is forced. Additionally, disallowing a line break makes it clear that the identifier is actually a tag for a template string. Patch originally by mitchellwills (thanks!). llvm-svn: 356447
* [clang-format] Propagate inferred language to getLLVMStyle() in ↵Jordan Rupprecht2019-03-131-0/+5
| | | | | | | | getPredefinedStyle() rC355158 added an optional language parameter to getLLVMStyle(), but this parameter was not used in getPredefinedStyle(). Because unit tests directly specify the style, this codepath wasn't tested. Add an additional unit test for getStyle(). llvm-svn: 356099
* [clang-format] [PR25010] AllowShortIfStatementsOnASingleLine not working if ↵Paul Hoad2019-03-132-11/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | an "else" statement is present Summary: Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010 Code like: ``` if(true) var++; else { var--; } ``` is reformatted to be ``` if (true) var++; else { var--; } ``` Even when `AllowShortIfStatementsOnASingleLine` is true The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine This suppresses the clause prevents the merging of the if when there is a compound else Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk Reviewed By: reuk Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits Tags: #clang-tools-extra Differential Revision: https://reviews.llvm.org/D59087 llvm-svn: 356031
OpenPOWER on IntegriCloud