summaryrefslogtreecommitdiff
path: root/lib/Format
Commit message (Collapse)AuthorAgeFilesLines
* [Format] Add format check for throwing negative numbersBrian Gesiak2019-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The code `throw -1;` is currently formatted by clang-format as `throw - 1;`. This diff adds a fix for this edge case and a test to check for this in the future. For context, I am looking into a related bug in the clang-formatting of coroutine keywords: `co_yield -1;` is also reformatted in this manner as `co_yield - 1;`. A later diff will add these changes and tests for the `co_yield` and `co_return` keywords. Patch by Jonathan Thomas (jonathoma)! Reviewers: modocache, sammccall, Quuxplusone Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D69144 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375258 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] fix regression recognizing casts in Obj-C callsKrasimir Georgiev2019-10-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r373922 added checks for a few tokens that, following an `)` make it unlikely that the `)` is the closing paren of a cast expression. The specific check for `tok::l_square` there introduced a regression for casts of Obj-C calls, like: ``` (cast)[func arg] ``` From the tests added in r373922, I believe the `tok::l_square` case is added to capture the case where a non-cast `)` is directly followed by an attribute specifier, like: ``` int f(int x) [[noreturn]]; ``` I've specialized the code to look for such attribute specifier instead of `tok::l_square` in general. Also, I added a regression test and moved the test cases added in r373922 to an already existing place documenting other instances of historically misidentified casts. Reviewers: MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69164 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375247 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] throws an incorrect assertion in consumeToken() formatting ↵Paul Hoad2019-10-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the MSVC stl Summary: An incorrect assertion is thrown when clang-formatting MSVC's STL library ``` Assertion failed: !Line.startsWith(tok::hash), file C:/llvm/llvm-project/clang/lib/Format/TokenAnnotator.cpp, line 847 Stack dump: 0. Program arguments: C:\llvm\build\bin\clang-format.exe -i -n ./stl/inc/xkeycheck.h ``` ``` Enable warning C4005 to find the forbidden define. ``` Reviewers: mitchell-stellar, STL_MSFT, klimek, krasimir Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang-format, #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D68707 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374399 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Update noexcept reference qualifiers detectionKrasimir Georgiev2019-10-091-14/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r373165 fixed an issue where a templated noexcept member function with a reference qualifier would be indented more than expected: ``` // Formatting produced with LLVM style with AlwaysBreakTemplateDeclarations: Yes // before r373165: struct f { template <class T> void bar() && noexcept {} }; // after: struct f { template <class T> void bar() && noexcept {} }; ``` The way this is done is that in the AnnotatingParser in `lib/FormatTokenAnnotator.cpp` the determination of the usage of a `&` or `&&` (the line in determineTokenType ``` Current.Type = determineStarAmpUsage(... ``` is not performed in some cases anymore, combining with a few additional related checks afterwards. The net effect of these checks results in the `&` or `&&` token to start being classified as `TT_Unknown` in cases where before `r373165` it would be classified as `TT_UnaryOperator` or `TT_PointerOrReference` by `determineStarAmpUsage`. This inadvertently caused 2 classes of regressions I'm aware of: - The address-of `&` after a function assignment would be classified as `TT_Unknown`, causing spaces to surround it, disregarding style options: ``` // before r373165: void (*fun_ptr)(void) = &fun; // after: void (*fun_ptr)(void) = & fun; ``` - In cases where there is a function declaration list -- looking macro between a template line and the start of the function declaration, an `&` as part of the return type would be classified as `TT_Unknown`, causing spaces to surround it: ``` // before r373165: template <class T> DEPRECATED("lala") Type& foo(); // after: template <class T> DEPRECATED("lala") Type & foo(); ``` In these cases the problems are rooted in the skipping of the classification of a `&` (and similarly `&&`) by determineStarAmpUsage which effects the formatting decisions later in the pipeline. I've looked into the goal of r373165 and noticed that replacing `noexcept` with `const` in the given example produces no extra indentation with the old code: ``` // before r373165: struct f { template <class T> int foo() & const {} }; struct f { template <class T> int foo() & noexcept {} }; ``` I investigated how clang-format annotated these two examples differently to determine the places where the processing of both diverges in the pipeline. There were two places where the processing diverges, causing the extra indent in the `noexcept` case: 1. The `const` is annotated as a `TT_TrailingAnnotation`, whereas `noexcept` is annotated as `TT_Unknown`. I've updated the `determineTokenType` function to account for this by adding a missing `tok:kw_noexcept` to the clause that marks a token as `TT_TrailingAnnotation`. 2. The `&` in the second example is wrongly identified as `TT_BinaryOperator` in `determineStarAmpUsage`. This is the reason for the extra indentation -- clang-format gets confused and thinks this is an expression. I've updated `determineStarAmpUsage` to check for `tok:kw_noexcept`. With these two updates in place, the additional parsing introduced by r373165 becomes unnecessary and all added tests pass (with updates, as now clang-format respects the style configuration for spaces around the `&` in the test examples). I've removed these additions and added regression tests for the cases above. Reviewers: AndWass, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: cfe-commits Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D68695 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374172 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] [PR27004] omits leading space for noexcept when formatting ↵Paul Hoad2019-10-071-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | operator delete() Summary: clang-format is incorrectly thinking the parameter parens are part of a cast operation, this is resulting in there sometimes being not space between the paren and the noexcept (and other keywords like volatile etc..) ``` void operator++(int) noexcept; void operator++(int &) noexcept; void operator delete(void *, std::size_t, const std::nothrow_t &)noexcept; ``` Reviewers: klimek, owenpan, mitchell-stellar Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D68481 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373922 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] SpacesInSquareBrackets should affect lambdas with parameters tooPaul Hoad2019-10-051-3/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes the `SpacesInSquareBrackets` setting also apply to C++ lambdas with parameters. Looking through the revision history, it appears support for only array brackets was added, and lambda brackets were ignored. Therefore, I am inclined to think it was simply an omission, rather than a deliberate choice. See https://bugs.llvm.org/show_bug.cgi?id=17887 and https://reviews.llvm.org/D4944. Reviewers: MyDeveloperDay, reuk, owenpan Reviewed By: MyDeveloperDay Subscribers: cfe-commits Patch by: mitchell-stellar Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D68473 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373821 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] C++11 braced lists should respect the SpacesInParentheses settingPaul Hoad2019-10-041-3/+6
| | | | | | | | | | | | | | | | | | | | | Summary: According to the clang-format documentation, "Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place. If the braced list follows a name (e.g. a type or variable name), clang-format formats as if the `{}` were the parentheses of a function call with that name." This patch furthers the treatment of C++11 braced list braces as parentheses by respecting the `SpacesInParentheses` setting. Reviewers: MyDeveloperDay, reuk, owenpan Reviewed By: MyDeveloperDay Subscribers: cfe-commits Tags: #clang-format, #clang Patch By: mitchell-stellar Differential Revision: https://reviews.llvm.org/D68415 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373751 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] [PR43531] clang-format damages "alternative representations" ↵Paul Hoad2019-10-041-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for operators Summary: https://bugs.llvm.org/show_bug.cgi?id=43531 Fix for clang-format incorrectly handles "alternative operators" as described by https://en.cppreference.com/w/cpp/language/operator_alternative compl = ~ not = ! these are unary operators, and clang-format will remove the space between them and a numeric constant this incorrectly formats the following code ``` int a compl 5; int a not 5; ``` into: ``` int a compl5; int a not5; ``` The code adds FIXME unit tests for "alternative token" representations for {} [] and # as defined by the same link, which would require a more detailed change to the FormatTokenLexer Reviewers: klimek, reuk, owenpan, mitchell-stellar, STL_MSFT Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang-format, #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D68332 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373750 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] [PR42417] clang-format inserts a space after '->' for ↵Paul Hoad2019-10-041-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | operator->() overloading Summary: https://bugs.llvm.org/show_bug.cgi?id=42417 This revision removes the extra space between the opertor-> and the parens () ``` class Bug { auto operator-> () -> int*; auto operator++(int) -> int; }; ``` Reviewers: klimek, owenpan, byoungyoung, mitchell-stellar Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D68242 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373746 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] [PR43338] C# clang format has space issues betweern C# only ↵Paul Hoad2019-10-043-5/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | keywords Summary: When formatting C# there can be issues with a lack of spaces between `using (` , `foreach (` and generic types The C# code ``` public class Foo { Dictionary<string,string> foo; } ``` will be formatted as ``` public class Foo { Dictionary<string, string>foo; ^^^^^ missing a space } ``` This revision also reverts some of {D66662} in order to make this cleaner and resolve an issues seen by @owenpan that the formatting didn't add a space when not in a code block This also transforms C# foreach commands to be seen as tok::kw_for commands (to ensure foreach gets the same Brace Wrapping behavior as for without littering the code with `if(Style.isCSharp())` Reviewers: owenpan, klimek, russellmcc, mitchell-stellar Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D67660 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373709 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] [PR43333] Fix C# breaking before function name when using ↵Paul Hoad2019-10-043-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Attributes Summary: This is a fix for https://bugs.llvm.org/show_bug.cgi?id=43333 This comes with 3 main parts - C# attributes cause function names on a new line even when AlwaysBreakAfterReturnType is set to None - Add AlwaysBreakAfterReturnType to None by default in the Microsoft style, - C# unit tests are not using Microsoft style (which we created to define the default C# style to match a vanilla C# project). Reviewers: owenpan, klimek, russellmcc, mitchell-stellar Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang-tools-extra, #clang, #clang-format Differential Revision: https://reviews.llvm.org/D67629 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373707 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Add ability to wrap braces after multi-line control statementsPaul Hoad2019-10-033-21/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Change the BraceWrappingFlags' AfterControlStatement from a bool to an enum with three values: * "Never": This is the default, and does not do any brace wrapping after control statements. * "MultiLine": This only wraps braces after multi-line control statements (this really only happens when a ColumnLimit is specified). * "Always": This always wraps braces after control statements. The first and last options are backwards-compatible with "false" and "true", respectively. The new "MultiLine" option is useful for when a wrapped control statement's indentation matches the subsequent block's indentation. It makes it easier to see at a glance where the control statement ends and where the block's code begins. For example: ``` if ( foo && bar ) { baz(); } ``` vs. ``` if ( foo && bar ) { baz(); } ``` Short control statements (1 line) do not wrap the brace to the next line, e.g. ``` if (foo) { bar(); } else { baz(); } ``` Reviewers: sammccall, owenpan, reuk, MyDeveloperDay, klimek Reviewed By: MyDeveloperDay Subscribers: MyDeveloperDay, cfe-commits Patch By: mitchell-stellar Tags: #clang-format, #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D68296 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373647 91177308-0d34-0410-b5e6-96231b3b80d8
* [ClangFormat] Future-proof Standard option, allow floating or pinning to ↵Sam McCall2019-10-021-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arbitrary lang version Summary: The historical context: - clang-format was written when C++11 was current, and the main language-version concern was >> vs > > template-closers. An option was added to allow selection of the 03/11 behavior, or auto-detection. - there was no option to choose simply "latest standard" so anyone who didn't ever want 03 behavior or auto-detection specified Cpp11. - In r185149 this option started to affect lexer mode. - no options were added to cover c++14, as parsing/formatting didn't change that much. The usage of Cpp11 to mean "latest" became codified e.g. in r206263 - c++17 added some new constructs. These were mostly backwards-compatible and so not used in old programs, so having no way to turn them off was OK. - c++20 added some new constructs and keywords (e.g. co_*) that changed the meaning of existing programs, and people started to complain that the c++20 parsing couldn't be turned off. New plan: - Default ('Auto') behavior remains unchanged: parse as latest, format template-closers based on input. - Add new 'Latest' option that more clearly expresses the intent "use modern features" that many projects have chosen for their .clang-format files. - Allow pinning to *any* language version, using the same name as clang -std: c++03, c++11, c++14 etc. These set precise lexer options, and any clang-format code depending on these can use a >= check. - For backwards compatibility, `Cpp11` is an alias for `Latest`, not `c++11`. This matches the historical documented semantics of this option. This spelling (and `Cpp03`) are deprecated. Reviewers: klimek, modocache Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67541 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373439 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] [PR43372] - clang-format shows replacements in DOS files when ↵Paul Hoad2019-10-011-3/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | no replacement is needed Summary: This is a patch to fix PR43372 (https://bugs.llvm.org/show_bug.cgi?id=43372) - clang-format can't format file with includes, ( which really keep providing replacements for already sorted headers.) A similar issue was addressed by @krasimir in {D60199}, however, this seemingly only prevented the issue when the files being formatted did not contain windows line endings (\r\n) It's possible this is related to https://twitter.com/StephanTLavavej/status/1176722938243895296 given who @STL_MSFT works for! As people often used the existence of replacements to determine if a file needs clang-formatting, this is probably pretty important for windows users There may be a better way of comparing 2 strings and ignoring \r (which appear in both Results and Code), I couldn't choose between this idiom or the copy_if approach, but I'm happy to change it to whatever people consider more performant. Reviewers: krasimir, klimek, owenpan, ioeric Reviewed By: krasimir Subscribers: cfe-commits, STL_MSFT, krasimir Tags: #clang-format, #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D68227 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373388 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Reference qualifiers in member templates causing extra ↵Paul Hoad2019-09-291-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | indentation. Summary: The following code ``` struct f { template <class T> void bar() && noexcept {} }; ``` will be formatted to the following with LLVM style, and `AlwaysBreakTemplateDeclarations: Yes` ``` struct f { template <class T> void bar() && noexcept {} }; ``` The indentation of the `void bar()` line is wrong. Reviewers: klimek, owenpan, krasimir, timwoj, MyDeveloperDay Reviewed By: klimek, MyDeveloperDay Subscribers: MyDeveloperDay, ilya-biryukov, llvm-commits, cfe-commits Patch By: AndWass Tags: #clang-format, #clang, #llvm Differential Revision: https://reviews.llvm.org/D68072 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373165 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r373056: [clang-format] Reference qualifiers in member templates ↵Ilya Biryukov2019-09-271-12/+4
| | | | | | | | causing extra indentation Reason: this breaks unit tests. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373059 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Reference qualifiers in member templates causing extra ↵Ilya Biryukov2019-09-271-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | indentation The following code ``` struct f { template <class T> void bar() && noexcept {} }; ``` will be formatted to the following with LLVM style, and `AlwaysBreakTemplateDeclarations: Yes` ``` struct f { template <class T> void bar() && noexcept {} }; ``` The indentation of the `void bar()` line is wrong. Patch by Andreas Wass (AndWass)! Differential Revision: https://reviews.llvm.org/D68072 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373056 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Add SortPriority fields to fix -Wmissing-field-initializers ↵Fangrui Song2019-09-261-5/+7
| | | | | | after D64695/r372919 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372939 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Modified SortIncludes and IncludeCategories to priority for ↵Paul Hoad2019-09-251-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | sorting #includes within the Group Category. Summary: This new Style rule is made as a part of adding support for NetBSD KNF in clang-format. NetBSD have it's own priority of includes which should be followed while formatting NetBSD code. This style sorts the Cpp Includes according to the priorities of NetBSD, as mentioned in the [Style Guide](http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style?rev=HEAD&content-type=text/x-cvsweb-markup) The working of this Style rule shown below: **Configuration:** This revision introduces a new field under IncludeCategories named `SortPriority` which defines the priority of ordering the `#includes` and the `Priority` will define the categories for grouping the `#include blocks`. Reviewers: cfe-commits, mgorny, christos, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: lebedev.ri, rdwampler, christos, mgorny, krytarowski Patch By: Manikishan Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D64695 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372919 91177308-0d34-0410-b5e6-96231b3b80d8
* Clang-format: Add Whitesmiths indentation stylePaul Hoad2019-09-223-0/+25
| | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for the Whitesmiths indentation style to clang-format. It’s an update to a patch submitted in 2015 (D6833), but reworks it to use the newer API. There are still some issues with this patch, primarily around `switch` and `case` support. The added unit test won’t currently pass because of the remaining issues. Reviewers: mboehme, MyDeveloperDay, djasper Reviewed By: MyDeveloperDay Subscribers: krasimir, MyDeveloperDay, echristo, cfe-commits Patch By: @timwoj (Tim Wojtulewicz) Tags: #clang Differential Revision: https://reviews.llvm.org/D67627 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372497 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format][PR41899] PointerAlignment: Left leads to useless space in ↵Paul Hoad2019-09-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | lambda intializer expression Summary: https://bugs.llvm.org/show_bug.cgi?id=41899 ```auto lambda = [&a = a]() { a = 2; };``` is formatted as ```auto lambda = [& a = a]() { a = 2; };``` With an extra space if PointerAlignment is set to Left > The space "& a" looks strange when there is no type in the lambda's intializer expression. This can be worked around with by setting "PointerAlignment: Right", but ideally "PointerAlignment: Left" would not add a space in this case. Reviewers: klimek, owenpan, krasimir, timwoj Reviewed By: klimek Subscribers: cfe-commits Tags: #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D67718 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372249 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format][PR41964] Fix crash with SIGFPE when TabWidth is set to 0 and ↵Paul Hoad2019-09-183-17/+26
| | | | | | | | | | | | | | | | | | | | | | | | | line starts with tab Summary: clang-format 8.0 crashes with SIGFPE (floating point exception) when formatting following file: app.cpp: void a() { //line starts with '\t' } $ clang-format -style='{TabWidth: 0}' app.cpp Reviewers: owenpan, klimek, russellmcc, timwoj Reviewed By: klimek Subscribers: cfe-commits Tags: #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D67670 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372246 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Fix cleanup of `AnnotatedLine` to include children nodes.Yitzhak Mandelbaum2019-09-171-11/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: AnnotatedLine has a tree structure, and things like the body of a lambda will be a child of the lambda expression. For example, [&]() { foo(a); }; will have an AnnotatedLine with a child: [&]() {}; '- foo(a); Currently, when the `Cleaner` class analyzes the affected lines, it does not cleanup the lines' children nodes, which results in missed cleanup opportunities, like the lambda body in the example above. This revision extends the algorithm to visit children, thereby fixing the above problem. Patch by Eric Li. Reviewers: krasimir Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67659 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372129 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format: Add support for formatting (some) lambdas with explicit ↵Nico Weber2019-09-132-3/+22
| | | | | | | | | | | | | | template parameters. This patch makes cases work where the lambda's template list doesn't contain any of + - ! ~ / % << | || && ^ == != >= <= ? : true false (see added FIXME). Ports r359967 to clang-format. Differential Revision: https://reviews.llvm.org/D67246 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371854 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] [PR43100] clang-format C# support does not add a space ↵Paul Hoad2019-09-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between "using" and paren Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=43100 Formatting using statement in C# with clang-format removes the space between using and paren even when SpaceBeforeParens is ! ``` using(FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize : 1)) ``` this change simply overcomes this for when using C# settings in the .clang-format file ``` using (FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize : 1)) ``` All FormatTests pass.. ``` [==========] 688 tests from 21 test cases ran. (88508 ms total) [ PASSED ] 688 tests. ``` Reviewers: djasper, klimek, owenpan Reviewed By: owenpan Subscribers: llvm-commits, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66662 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371720 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Add new style option IndentGotoLabelsPaul Hoad2019-09-123-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This option determines whether goto labels are indented according to scope. Setting this option to false causes goto labels to be flushed to the left. This is mostly copied from [[ http://lists.llvm.org/pipermail/cfe-dev/2015-September/045014.html | this patch ]] submitted by Christian Neukirchen that didn't make its way into trunk. ``` true: false: int f() { vs. int f() { if (foo()) { if (foo()) { label1: label1: bar(); bar(); } } label2: label2: return 1; return 1; } } ``` Reviewers: klimek, MyDeveloperDay Reviewed By: MyDeveloperDay Subscribers: cfe-commits Tags: #clang, #clang-tools-extra Patch by: tetsuo-cpp Differential Revision: https://reviews.llvm.org/D67037 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371719 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Apply BAS_AlwaysBreak to C++11 braced listsOwen Pan2019-09-101-1/+3
| | | | | | | | See PR18455. Differential Revision: https://reviews.llvm.org/D67395 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371571 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format: [JS] handle `as const`.Martin Probst2019-08-261-0/+4
| | | | | | | | | | | | | | | | | | | | Summary: TypeScript 3.4 supports casting into a const type using `as const`: const x = {x: 1} as const; Previously, clang-format would insert a space after the `const`. With this patch, no space is inserted after the sequence `as const`. Reviewers: krasimir Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66736 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369916 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format: Disable across-block include reordering.Nico Weber2019-08-231-0/+21
| | | | | | Differential Revision: https://reviews.llvm.org/D66650 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369759 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Recognize ECMAScript module .mjs as JavaScriptFangrui Song2019-08-231-2/+3
| | | | | | | | | | | | | | PR43085. Recognize .mjs files as JavaScript. .mjs is the extension for ECMAScript modules. A specific extension (and associated content type javascript/esm) is introduced to differentiate it from CommonJS modules and solve some interoperability problems. Differential Revision: https://reviews.llvm.org/D66584 Patch by Fergal Daly git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369732 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Fix a bug that joins template closer and =Owen Pan2019-08-181-1/+1
| | | | | | | | | | Also fixes the documentation for SpaceBeforeAssignmentOperators. See discussions at https://reviews.llvm.org/D66332 Differential Revision: https://reviews.llvm.org/D66384 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369214 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Fix the bug that joins template closer and > or >>Owen Pan2019-08-161-0/+2
| | | | | | | | | | Also fixes a buggy test case. See PR42404 Differential Revision: https://reviews.llvm.org/D66332 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369157 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-143-6/+6
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368942 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Expand AllowShortBlocksOnASingleLine for WebKitOwen Pan2019-08-113-8/+20
| | | | | | | | See PR40840 Differential Revision: https://reviews.llvm.org/D66059 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368539 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Add SpaceInEmptyBlock option for WebKitOwen Pan2019-08-102-1/+4
| | | | | | | | See PR40840 Differential Revision: https://reviews.llvm.org/D65925 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368507 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] fix crash involving invalid preprocessor lineKrasimir Georgiev2019-08-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368280 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Fix a bug that doesn't break braces before unions for AllmanOwen Pan2019-08-021-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D65631 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367648 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format clang/lib/FormatNico Weber2019-07-295-19/+17
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367225 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format: Support `if CONSTEXPR` if CONSTEXPR is a macro.Nico Weber2019-07-274-10/+19
| | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367167 91177308-0d34-0410-b5e6-96231b3b80d8
* [Format] getFormattingLangOpts: make LS_Auto uses LS_Cpp11 lexing ruleFangrui Song2019-07-241-4/+7
| | | | | | | | | | Suggested by sammccall in post-commit review of D65183 Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D65194 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366883 91177308-0d34-0410-b5e6-96231b3b80d8
* [Format] Make it easy to add new format::FormatStyle::LanguageStandard. NFCIFangrui Song2019-07-242-6/+6
| | | | | | | | | | | | | | Preparatory change for D65043. We current use `!=LS_Cpp03` to enable language standards 11,14,17, and 2a. `>=LS_Cpp11` is better if we decide to add new LanguageStandard in the future. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D65183 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366876 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format: Fix namespace end comments for namespaces with attributes and ↵Nico Weber2019-07-232-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366831 91177308-0d34-0410-b5e6-96231b3b80d8
* Adds support for formatting NS_CLOSED_ENUM and CF_CLOSED_ENUM alongside ↵Ben Hamilton2019-07-223-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366719 91177308-0d34-0410-b5e6-96231b3b80d8
* [Format/ObjC] Avoid breaking between unary operators and operandsBen Hamilton2019-07-191-0/+2
| | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366592 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Don't detect call to ObjC class method as C++11 attribute ↵Ben Hamilton2019-07-161-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366267 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366177 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format: Add new style option AlignConsecutiveMacrosSam McCall2019-07-023-0/+130
| | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@364938 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-format: better handle namespace macrosFrancois Ferrand2019-06-068-50/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@362740 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Allow configuring list of function-like macros that resolve ↵Francois Ferrand2019-05-294-7/+15
| | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@361986 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang-format] Fixed self assignmentDavid Bolvansky2019-05-151-1/+0
| | | | | | | | | | | | | | Reviewers: MyDeveloperDay, RKSimon Reviewed By: MyDeveloperDay Subscribers: RKSimon, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61281 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360810 91177308-0d34-0410-b5e6-96231b3b80d8