summaryrefslogtreecommitdiffstats
path: root/clang/unittests/Format
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[ClangFormat] IndentWrappedFunctionNames should be true in the ↵Ben Hamilton2017-12-141-5/+2
| | | | | | | | | | | google ObjC style" This reverts commit 37e69667f748e1458b46483b7c1b8f9ba33eec44. We're going to discuss its ramifications further before making a conclusion. llvm-svn: 320747
* [ClangFormat] IndentWrappedFunctionNames should be true in the google ObjC styleBen Hamilton2017-12-141-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we write the following code, it goes over 100 columns, so we need to wrap it: ``` - (VeryLongReturnTypeName)veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName; ``` Currently, clang-format with the google style aligns the method parameter names on the first column: ``` - (VeryLongReturnTypeName) veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName; ``` We'd like clang-format in the google style to align these to column 4 for Objective-C: ``` - (VeryLongReturnTypeName) veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName; ``` Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests Reviewers: krasimir, djasper, klimek Reviewed By: djasper Subscribers: cfe-commits, thakis Differential Revision: https://reviews.llvm.org/D41195 llvm-svn: 320714
* [c++20] P0515R3: Parsing support and basic AST construction for operator <=>.Richard Smith2017-12-141-0/+8
| | | | | | | | | | | | | | | Adding the new enumerator forced a bunch more changes into this patch than I would have liked. The -Wtautological-compare warning was extended to properly check the new comparison operator, clang-format needed updating because it uses precedence levels as weights for determining where to break lines (and several operators increased their precedence levels with this change), thread-safety analysis needed changes to build its own IL properly for the new operator. All "real" semantic checking for this operator has been deferred to a future patch. For now, we use the relational comparison rules and arbitrarily give the builtin form of the operator a return type of 'void'. llvm-svn: 320707
* [clang-format] Improve ObjC headers detection.Krasimir Georgiev2017-12-121-0/+11
| | | | | | | | | | | This patch improves detection of ObjC header files. Right now many ObjC headers, especially short ones, are categorized as C/C++. Way of filtering still isn't the best, as most likely it should be token-based. Contributed by jolesiak! llvm-svn: 320479
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* Fix bug where we wouldn't break columns over the limit.Manuel Klimek2017-12-041-0/+9
| | | | | | | | | | | | | | | | Before, we would not break: int a = foo(/* trailing */); when the end of /* trailing */ was exactly the column limit; the reason is that block comments can have an unbreakable tail length - in this case 2, for the trailing ");"; we would unconditionally account that when calculating the column state at the end of the token, but not correctly add it into the remaining column length before, as we do for string literals. The fix is to correctly account the trailing unbreakable sequence length into our formatting decisions for block comments. Line comments cannot have a trailing unbreakable sequence, so no change is needed for them. llvm-svn: 319642
* Better trade-off for excess characters vs. staying within the column limits.Manuel Klimek2017-12-011-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we break a long line like: Column limit: 21 | // foo foo foo foo foo foo foo foo foo foo foo foo The local decision when to allow protruding vs. breaking can lead to this outcome (2 excess characters, 2 breaks): // foo foo foo foo foo // foo foo foo foo foo // foo foo While strictly staying within the column limit leads to this strictly better outcome (fully below the column limit, 2 breaks): // foo foo foo foo // foo foo foo foo // foo foo foo foo To get an optimal solution, we would need to consider all combinations of excess characters vs. breaking for all lines, but that would lead to a significant increase in the search space of the algorithm for little gain. Instead, we blindly try both approches and·select the one that leads to the overall lower penalty. Differential Revision: https://reviews.llvm.org/D40605 llvm-svn: 319541
* clang-format: [JS] do not wrap after async/await.Martin Probst2017-11-301-0/+5
| | | | | | | | | | | | | | Summary: Otherwise automatic semicolon insertion can trigger, i.e. wrapping produces invalid syntax. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D40642 llvm-svn: 319415
* Restructure how we break tokens.Manuel Klimek2017-11-292-36/+115
| | | | | | | | | | | | | | | | | This fixes some bugs in the reflowing logic and splits out the concerns of reflowing from BreakableToken. Things to do after this patch: - Refactor the breakProtrudingToken function possibly into a class, so we can split it up into methods that operate on the common state. - Optimize whitespace compression when reflowing by using the next possible split point instead of the latest possible split point. - Retry different strategies for reflowing (strictly staying below the column limit vs. allowing excess characters if possible). Differential Revision: https://reviews.llvm.org/D40310 llvm-svn: 319314
* [clang-format] Add option to group multiple #include blocks when sorting ↵Krasimir Georgiev2017-11-271-0/+182
| | | | | | | | | | | | | | | | | | | | includes Summary: This patch allows grouping multiple #include blocks together and sort all includes as one big block. Additionally, sorted includes can be regrouped after sorting based on configured categories. Contributed by @KrzysztofKapusta! Reviewers: krasimir Reviewed By: krasimir Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D40288 llvm-svn: 319024
* clang-format: [JS] do not collapse short classes.Martin Probst2017-11-251-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: clang-format does not collapse short records, interfaces, unions, etc., but fails to do so if the record is preceded by certain modifiers (export, default, abstract, declare). This change skips over all modifiers, and thus handles all record definitions uniformly. Before: export class Foo { bar: string; } class Baz { bam: string; } After: export class Foo { bar: string; } class Baz { bam: string; } Reviewers: djasper Subscribers: klimek Differential Revision: https://reviews.llvm.org/D40430 llvm-svn: 318976
* clang-format: [JS] handle semis in generic types.Martin Probst2017-11-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: TypeScript generic type arguments can contain object (literal) types, which in turn can contain semicolons: const x: Array<{a: number; b: string;} = []; Previously, clang-format would incorrectly categorize the braced list as a block and terminate the line at the openening `{`, and then format the entire expression badly. With this change, clang-format recognizes `<` preceding a `{` as introducing a type expression. In JS, `<` comparison with an object literal can never be true, so the chance of introducing false positives here is very low. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D40424 llvm-svn: 318975
* clang-format: [JS] handle `for` as object label.Martin Probst2017-11-251-0/+5
| | | | | | | | | | | | Summary: Previously, clang-format would fail formatting `{for: 1}`. Reviewers: djasper Subscribers: klimek Differential Revision: https://reviews.llvm.org/D40441 llvm-svn: 318974
* clang-format: [JS] disable ASI on decorators.Martin Probst2017-11-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Automatic Semicolon Insertion in clang-format tries to guess if a line wrap should insert an implicit semicolong. The previous heuristic would not trigger ASI if a token was immediately preceded by an `@` sign: function foo(@Bar // <-- does not trigger due to preceding @ baz) {} However decorators can have arbitrary parameters: function foo(@Bar(param, param, param) // <-- precending @ missed baz) {} While it would be possible to precisely find the matching `@`, just conversatively disabling ASI for the entire line is simpler, while also not regressing ASI substatially. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D40410 llvm-svn: 318973
* [clang-format] Deduplicate using declarationsKrasimir Georgiev2017-11-241-4/+19
| | | | | | | | | | | | | | Summary: This deduplicated equivalent using declarations within a block. Reviewers: bkramer Reviewed By: bkramer Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D40435 llvm-svn: 318960
* clang-format: [JS] do not break in ArrayType[].Martin Probst2017-11-241-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: Wrapping between the type name and the array type indicator creates invalid syntax in TypeScript. Before: const xIsALongIdent: YJustBarelyFitsLinex []; // illegal syntax. After: const xIsALongIdent: YJustBarelyFitsLinex[]; Reviewers: djasper Subscribers: klimek Differential Revision: https://reviews.llvm.org/D40436 llvm-svn: 318959
* clang-format: [JS] do not wrap before yield.Martin Probst2017-11-241-0/+1
| | | | | | | | | | | | Summary: The same rules apply as for `return`. Reviewers: djasper Subscribers: klimek Differential Revision: https://reviews.llvm.org/D40431 llvm-svn: 318958
* clang-format: [JS] space between ! assert and in.Martin Probst2017-11-241-0/+1
| | | | | | | | | | | | | | | | Summary: Before: x = y!in z; After: x = y! in z; Reviewers: djasper Subscribers: klimek Differential Revision: https://reviews.llvm.org/D40433 llvm-svn: 318957
* clang-format: [JS] handle destructuring `of`.Martin Probst2017-11-241-0/+4
| | | | | | | | | | | | | | | | | | | | | Summary: Previously, clang-format would drop a space character between `of` and then following (non-identifier) token if the preceding token was part of a destructuring assignment (`}` or `]`). Before: for (const [a, b] of[]) {} After: for (const [a, b] of []) {} Reviewers: djasper Subscribers: klimek Differential Revision: https://reviews.llvm.org/D40411 llvm-svn: 318942
* clang-format: remove trailing lines in lamdas and arrow functions.Martin Probst2017-11-172-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: clang-format already removes empty lines at the beginning & end of blocks: int x() { foo(); // lines before and after will be removed. } However because lamdas and arrow functions are parsed as expressions, the existing logic to remove empty lines in UnwrappedLineFormatter doesn't handle them. This change special cases arrow functions in ContinuationIndenter to remove empty lines: x = []() { foo(); // lines before and after will now be removed. }; Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D40178 llvm-svn: 318537
* Implement more accurate penalty & trade-offs while breaking protruding tokens.Manuel Klimek2017-11-172-21/+154
| | | | | | | | For each line that we break in a protruding token, compute whether the penalty of breaking is actually larger than the penalty of the excess characters. Only break if that is the case. llvm-svn: 318515
* Refactor ContinuationIndenter's breakProtrudingToken logic.Manuel Klimek2017-11-142-3/+15
| | | | | | | | | | | Create more orthogonal pieces. The restructuring made it easy to try out several alternatives to D33589, and while none of the alternatives turned out to be the right solution, the underlying simplification of the structure is helpful. Differential Revision: https://reviews.llvm.org/D39900 llvm-svn: 318141
* [clang-format] Handle leading comments in using declarationDaniel Jasper2017-11-101-0/+7
| | | | | | | | | | This fixes clang-format internal assertion for the following code: /* override */ using std::string; Patch by Igor Sugak. Thank you. llvm-svn: 317901
* [clang-format] Support python-style comments in text protosKrasimir Georgiev2017-11-101-0/+85
| | | | | | | | | | | | | | Summary: This patch adds support for python-style comments in text protos. Reviewers: djasper Reviewed By: djasper Subscribers: bkramer, cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D39806 llvm-svn: 317886
* [clang-format] Sort using declarations by splitting on '::'Krasimir Georgiev2017-11-091-10/+61
| | | | | | | | | | | | | | Summary: This patch improves using declarations sorting. Reviewers: bkramer Reviewed By: bkramer Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D39786 llvm-svn: 317794
* [clang-format] Handle unary operator overload with arguments and specifiersDaniel Jasper2017-11-061-0/+1
| | | | | | | | | | | | Before: int operator++(int)noexcept; After: int operator++(int) noexcept; Patch by Igor Sugak. Thank you! llvm-svn: 317473
* [clang-format] Sort using-declarations case sensitively with a special case ↵Krasimir Georgiev2017-11-031-43/+12
| | | | | | | | | | | | | | | | | | | | for '_' Summary: This makes clang-format sort using declarations case-sensitive with the exception that '_' comes just before 'A'. This is better than the current case insensitive version, because it groups uppercase names in the same namespace together. Reviewers: bkramer Reviewed By: bkramer Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D39549 llvm-svn: 317325
* [clang-format] Handle CRLF correctly when formatting escaped newlinesKrasimir Georgiev2017-10-301-4/+30
| | | | | | | | | | Subscribers: klimek Differential Revision: https://reviews.llvm.org/D39420 Contributed by @peterbudai! llvm-svn: 316910
* [clang-format] Format raw string literalsKrasimir Georgiev2017-10-303-0/+748
| | | | | | | | | | | | | | | Summary: This patch adds raw string literal formatting. Reviewers: djasper, klimek Reviewed By: klimek Subscribers: klimek, mgorny Differential Revision: https://reviews.llvm.org/D35943 llvm-svn: 316903
* [clang-format] Sort whole block of using declarations while partially formattingKrasimir Georgiev2017-10-181-2/+30
| | | | | | | | | | | | | | | | Summary: This patch enables sorting the full block of using declarations when some line is affected. Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D39024 llvm-svn: 316130
* [clang-format] Break non-trailing comments, try 2Krasimir Georgiev2017-10-162-0/+88
| | | | | | | | | | | | | | | | | | | | Summary: This patch enables `BreakableToken` to manage the formatting of non-trailing block comments. It is a refinement of https://reviews.llvm.org/D37007. We discovered that the optimizer outsmarts us on cases where breaking the comment costs considerably less than breaking after the comment. This patch addresses this by ensuring that a newline is inserted between a block comment and the next token. Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D37695 llvm-svn: 315893
* [clang-format] Fix regression about short functions after #elseKrasimir Georgiev2017-10-021-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a regression introduced in r312904, where the formatter confuses the `else` in `#else` with an `else` of an `if-else` statement. For example, formatting this code with google style ``` #ifdef A int f() {} #else int f() {} #endif ``` resulted in ``` #ifdef A int f() {} #else int f() { } #endif ``` Reviewers: sammccall Reviewed By: sammccall Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D37973 llvm-svn: 314683
* clang-format/java: Unbreak genenrics formatting after r299952.Nico Weber2017-09-271-0/+5
| | | | | | | | | | | | | | https://reviews.llvm.org/rL299952 merged '>>>' tokens into a single JavaRightLogicalShift token. This broke formatting of generics nested more than two deep, e.g. Foo<Bar<Baz>>> because the '>>>' now weren't three '>' for parseAngle(). Luckily, just deleting JavaRightLogicalShift fixes things without breaking the test added in r299952, so do that. https://reviews.llvm.org/D38291 llvm-svn: 314325
* [clang-format] Fix FixNamespaceComments when BraceWrapping AfterNamespace is ↵Marek Kurdej2017-09-271-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | true. Summary: NamespaceEndCommentsFixer did not fix namespace comments when the brace opening the namespace was not on the same line as the "namespace" keyword. It occurs in Allman, GNU and Linux styles and whenever BraceWrapping.AfterNamespace is true. Before: ```lang=cpp namespace a { void f(); void g(); } ``` After: ```lang=cpp namespace a { void f(); void g(); } // namespace a ``` Reviewers: krasimir Reviewed By: krasimir Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D37904 llvm-svn: 314279
* [clang-format] Adjust space around &/&& of structured bindingsChih-Hung Hsieh2017-09-271-9/+44
| | | | | | | | | | | Keep space before or after the &/&& tokens, but not both. For example, auto [x,y] = a; auto &[xr, yr] = a; // LLVM style auto& [xr, yr] = a; // google style Differential Revision:https://reviews.llvm.org/D35743 llvm-svn: 314264
* clang-format/java: Always put space after `assert` keyword.Nico Weber2017-09-251-0/+1
| | | | | | Previously, it was missing if the expression after the assert started with a (. llvm-svn: 314172
* [clang-format] Ignore case and stable sort using-declarationsKrasimir Georgiev2017-09-221-0/+71
| | | | | | | | | | | | | | | | Summary: This ignores case while sorting using-declarations, fixing a case where `_` would appear between lowercase and uppercase characters. It also applies stable sort, so that replacements for the exact same using declarations are not generated. Reviewers: klimek, alexfh Reviewed By: alexfh Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D37263 llvm-svn: 313963
* Fix clang-format's detection of structured bindings.Manuel Klimek2017-09-201-0/+5
| | | | | | | | | | | | | | | | | | | Correctly determine when [ is part of a structured binding instead of a lambda. To be able to reuse the implementation already available, this patch also: - sets the Previous link of FormatTokens in the UnwrappedLineParser - moves the isCppStructuredBinding function into FormatToken Before: auto const const &&[x, y] { A *i }; After: auto const const && [x, y]{A * i}; Fixing formatting of the type of the structured binding is still missing. llvm-svn: 313742
* Fix formatting of lambda introducers with initializers.Manuel Klimek2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | | | | Most of the work was already done when we introduced a look-behind based lambda introducer detection. This patch finishes the transition by completely relying on the simple lambda introducer detection and simply recursing into normal brace-parsing code to parse until the end of the introducer. This fixes initializers in lambdas, including nested lambdas. Before: auto a = [b = [c = 42]{}]{}; auto b = [c = &i + 23]{}; After: auto a = [b = [c = 42] {}] {}; auto b = [c = &i + 23] {}; llvm-svn: 313622
* [clang-format] New flag - BraceWrapping.AfterExternBlockKrasimir Georgiev2017-09-151-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **"extern C part"** **Problem:** Due to the lack of "brace wrapping extern" flag, clang format does parse the block after **extern** keyword moving the opening bracket to the header line always! **Patch description:** A new style added, new configuration flag - **BraceWrapping.AfterExternBlock** that allows us to decide whether we want a break before brace or not. Reviewers: djasper, krasimir Reviewed By: krasimir Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D37845 Contributed by @PriMee! llvm-svn: 313354
* clang-format: [JS] wrap and indent `goog.setTestOnly` calls.Martin Probst2017-09-111-2/+6
| | | | | | | | | | | | | | | | | | Summary: While `goog.setTestOnly` usually appears in the imports section of a file, it is not actually an import, and also usually doesn't take long parameters (nor namespaces as a parameter, it's a description/message that should be wrapped). This fixes a regression where a `goog.setTestOnly` call nested in a function was not wrapped. Reviewers: djasper Subscribers: klimek Differential Revision: https://reviews.llvm.org/D37685 llvm-svn: 312918
* [clang-format] Fixed one-line if statementKrasimir Georgiev2017-09-111-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: **Short overview:** Fixed bug: https://bugs.llvm.org/show_bug.cgi?id=34001 Clang-format bug resulting in a strange behavior of control statements short blocks. Different flags combinations do not guarantee expected result. Turned on option AllowShortBlocksOnASingleLine does not work as intended. **Description of the problem:** Cpp source file UnwrappedLineFormatter does not handle AllowShortBlocksOnASingleLine flag as it should. Putting a single-line control statement without any braces, clang-format works as expected (depending on AllowShortIfStatementOnASingleLine or AllowShortLoopsOnASingleLine value). Putting a single-line control statement in braces, we can observe strange and incorrect behavior. Our short block is intercepted by tryFitMultipleLinesInOne function. The function returns a number of lines to be merged. Unfortunately, our control statement block is not covered properly. There are several if-return statements, but none of them handles our block. A block is identified by the line first token and by left and right braces. A function block works as expected, there is such an if-return statement doing proper job. A control statement block, from the other hand, falls into strange conditional construct, which depends on BraceWrapping.AfterFunction flag (with condition that the line’s last token is left brace, what is possible in our case) or goes even further. That should definitely not happen. **Description of the patch:** By adding three different if statements, we guarantee that our short control statement block, however it looks like (different brace wrapping flags may be turned on), is handled properly and does not fall into wrong conditional construct. Depending on appropriate options we return either 0 (when something disturbs our merging attempt) or let another function (tryMergeSimpleBlock) take the responsibility of returned result (number of merged lines). Nevertheless, one more correction is required in mentioned tryMergeSimpleBlock function. The function, previously, returned either 0 or 2. The problem was that this did not handle the case when our block had the left brace in a separate line, not the header one. After change, after adding condition, we return the result compatible with block’s structure. In case of left brace in the header’s line we do everything as before the patch. In case of left brace in a separate line we do the job similar to the one we do in case of a “non-header left brace” function short block. To be precise, we try to merge the block ignoring the header line. Then, if success, we increment our returned result. **After fix:** **CONFIG:** ``` AllowShortBlocksOnASingleLine: true AllowShortIfStatementsOnASingleLine: true BreakBeforeBraces: Custom BraceWrapping: { AfterClass: true, AfterControlStatement: true, AfterEnum: true, AfterFunction: true, AfterNamespace: false, AfterStruct: true, AfterUnion: true, BeforeCatch: true, BeforeElse: true } ``` **BEFORE:** ``` if (statement) doSomething(); if (statement) { doSomething(); } if (statement) { doSomething(); } if (statement) { doSomething(); } if (statement) doSomething(); if (statement) { doSomething1(); doSomething2(); } ``` **AFTER:** ``` if (statement) doSomething(); if (statement) { doSomething(); } if (statement) { doSomething(); } if (statement) { doSomething(); } if (statement) doSomething(); if (statement) { doSomething1(); doSomething2(); } ``` Contributed by @PriMee! Reviewers: krasimir, djasper Reviewed By: krasimir Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D37140 llvm-svn: 312904
* [clang-format] Add support for C++17 structured bindings.Marek Kurdej2017-09-071-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before: ``` auto[a, b] = f(); ``` After: ``` auto [a, b] = f(); ``` or, if SpacesInSquareBrackets is true: ``` auto [ a, b ] = f(); ``` Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D37132 llvm-svn: 312723
* clang-format: Fix indentation of macros in include guards (after r312125).Daniel Jasper2017-09-041-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | Before: #ifndef A_H #define A_H #define A() \ int i; \ int j; #endif // A_H After: #ifndef A_H #define A_H #define A() \ int i; \ int j; #endif // A_H llvm-svn: 312484
* clang-format: Fix formatting of for loops with multiple increments.Daniel Jasper2017-09-031-0/+4
| | | | | | This fixes llvm.org/PR34366. llvm-svn: 312437
* Disable clang-format's MemoizationTest as it becomes prohibitive with ↵David Blaikie2017-08-311-0/+5
| | | | | | | | | | | | | | | | EXPENSIVE_CHECKS EXPENSIVE_CHECKS enables libstdc++'s library consistency checks, which includes checking the container passed to std::priority_queue for its well-formedness. This makes the clang-format memoization too expensive, so disable it. (it's a necessary feature of libstdc++'s consistency checks that it ruins the required scalability of C++ standard library features - so these workarounds are to be expected if a test ever tries to test scalability in some way, like this test does) llvm-svn: 312268
* clang-format: Add preprocessor directive indentationKrasimir Georgiev2017-08-302-3/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is an implementation for [bug 17362](https://bugs.llvm.org/attachment.cgi?bugid=17362) which adds support for indenting preprocessor statements inside if/ifdef/endif. This takes previous work from fmauch (https://github.com/fmauch/clang/tree/preprocessor_indent) and makes it into a full feature. The context of this patch is that I'm a VMware intern, and I implemented this because VMware needs the feature. As such, some decisions were made based on what VMware wants, and I would appreciate suggestions on expanding this if necessary to use-cases other people may want. This adds a new enum config option, `IndentPPDirectives`. Values are: * `PPDIS_None` (in config: `None`): ``` #if FOO #if BAR #include <foo> #endif #endif ``` * `PPDIS_AfterHash` (in config: `AfterHash`): ``` #if FOO # if BAR # include <foo> # endif #endif ``` This is meant to work whether spaces or tabs are used for indentation. Preprocessor indentation is independent of indentation for non-preprocessor lines. Preprocessor indentation also attempts to ignore include guards with the checks: 1. Include guards cover the entire file 2. Include guards don't have `#else` 3. Include guards begin with ``` #ifndef <var> #define <var> ``` This patch allows `UnwrappedLineParser::PPBranchLevel` to be decremented to -1 (the initial value is -1) so the variable can be used for indent tracking. Defects: * This patch does not handle the case where there's code between the `#ifndef` and `#define` but all other conditions hold. This is because when the #define line is parsed, `UnwrappedLineParser::Lines` doesn't hold the previous code line yet, so we can't detect it. This is out of the scope of this patch. * This patch does not handle cases where legitimate lines may be outside an include guard. Examples are `#pragma once` and `#pragma GCC diagnostic`, or anything else that does not change the meaning of the file if it's included multiple times. * This does not detect when there is a single non-preprocessor line in front of an include-guard-like structure where other conditions hold because `ScopedLineState` hides the line. * Preprocessor indentation throws off `TokenAnnotator::setCommentLineLevels` so the indentation of comments immediately before indented preprocessor lines is toggled on each run. Fixing this issue appears to be a major change and too much complexity for this patch. Contributed by @euhlmann! Reviewers: djasper, klimek, krasimir Reviewed By: djasper, krasimir Subscribers: krasimir, mzeren-vmw, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D35955 llvm-svn: 312125
* [clang-format] Do not format likely xmlKrasimir Georgiev2017-08-292-0/+18
| | | | | | | | | | | | | | | | | Summary: This patch detects the leading '<' in likely xml files and stops formatting in that case. A recent use of a Qt xml file with a .ts extension triggered this: http://doc.qt.io/qt-4.8/linguist-ts-file-format.html Reviewers: djasper Reviewed By: djasper Subscribers: sammccall, cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D37136 llvm-svn: 311999
* [clang-format] Fixed typedef enum brace wrappingKrasimir Georgiev2017-08-291-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **Typedef enum part** **Problem:** Clang format does not allow the flag **BraceWrapping.AfterEnum** control the case when our **enum** is preceded by **typedef** keyword (what is common in C language). **Patch description:** Added case to the **"AfterEnum"** flag when our enum does not start a line - is preceded by **typedef** keyword. **After fix:** **CONFIG:** ``` BreakBeforeBraces: Custom BraceWrapping: { AfterClass: true, AfterControlStatement: true, AfterEnum: true, AfterFunction: true, AfterNamespace: false, AfterStruct: true, AfterUnion: true, BeforeCatch: true, BeforeElse: true } ``` **BEFORE:** ``` typedef enum { a, b, c } SomeEnum; ``` **AFTER:** ``` typedef enum { a, b, c } SomeEnum; ``` Contributed by @PriMee! Reviewers: krasimir, djasper Reviewed By: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D37143 llvm-svn: 311998
* clang-format: [JS] simplify template string wrapping.Martin Probst2017-08-291-16/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, clang-format would try to wrap template string substitutions by indenting relative to the openening `${`. This helped with indenting structured strings, such as strings containing HTML, as the substitutions would be aligned according to the structure of the string. However it turns out that the overwhelming majority of template string + substitution usages are for substitutions into non-structured strings, e.g. URLs or just plain messages. For these situations, clang-format would often produce very ugly indents, in particular for strings containing no line breaks: return `<a href='http://google3/${file}?l=${row}'>${file}</a>(${ row },${ col }): `; This change makes clang-format indent template string substitutions as if they were string concatenation operations. It wraps +4 on overlong lines and keeps all operands on the same line: return `<a href='http://google3/${file}?l=${row}'>${file}</a>(${ row},${col}): `; While this breaks some lexical continuity between the `${` and `row}` here, the overall effects are still a huge improvement, and users can still manually break the string using `+` if desired. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D37142 llvm-svn: 311988
OpenPOWER on IntegriCloud