#
4ee70e00 |
| 14-Nov-2019 |
Mitchell Balan <mitchell@stellarscience.com> |
[clang-format] Fixed edge-case with SpacesInSquareBrackets with trailing bare "&" lambda capture.
Summary: Lambda captures allow for a lone `&` capture, so `&]` needs to be properly handled.
`int f
[clang-format] Fixed edge-case with SpacesInSquareBrackets with trailing bare "&" lambda capture.
Summary: Lambda captures allow for a lone `&` capture, so `&]` needs to be properly handled.
`int foo = [& ]() {}` is fixed to give `int foo = [ & ]() {}`
Reviewers: MyDeveloperDay
Reviewed by: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D70249
show more ...
|
#
335ac2eb |
| 12-Nov-2019 |
mydeveloperday <mydeveloperday@gmail.com> |
Allow additional file suffixes/extensions considered as source in main include grouping
Summary: By additional regex match, grouping of main include can be enabled in files that are not normally con
Allow additional file suffixes/extensions considered as source in main include grouping
Summary: By additional regex match, grouping of main include can be enabled in files that are not normally considered as a C/C++ source code. For example, this might be useful in templated code, where template implementations are being held in *Impl.hpp files. On the occassion, 'assume-filename' option description was reworded as it was misleading. It has nothing to do with `style=file` option and it does not influence sourced style filename.
Reviewers: rsmith, ioeric, krasimir, sylvestre.ledru, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch by: furdyna
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67750
show more ...
|
#
a75f8d98 |
| 12-Nov-2019 |
mydeveloperday <mydeveloperday@gmail.com> |
[clang-format] [PR36294] AlwaysBreakAfterReturnType works incorrectly for some operator functions
Summary: https://bugs.llvm.org/show_bug.cgi?id=36294
Addressing bug related to returning after retu
[clang-format] [PR36294] AlwaysBreakAfterReturnType works incorrectly for some operator functions
Summary: https://bugs.llvm.org/show_bug.cgi?id=36294
Addressing bug related to returning after return type not being honoured for some operator types.
``` $ bin/clang-format --style="{BasedOnStyle: llvm, AlwaysBreakAfterReturnType: TopLevelDefinitions}" /tmp/foo.cpp class Foo { public: bool operator!() const; bool operator<(Foo const &) const; bool operator*() const; bool operator->() const; bool operator+() const; bool operator-() const; bool f() const; };
bool Foo::operator!() const { return true; } bool Foo::operator<(Foo const &) const { return true; } bool Foo::operator*() const { return true; } bool Foo::operator->() const { return true; } bool Foo::operator+() const { return true; } bool Foo::operator-() const { return true; } bool Foo::f() const { return true; } ```
Reviewers: mitchell-stellar, klimek, owenpan, sammccall, rianquinn
Reviewed By: sammccall
Subscribers: merge_guards_bot, cfe-commits
Tags: #clang-format, #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D69573
show more ...
|
#
76ec6b1e |
| 06-Nov-2019 |
paulhoad <mydeveloperday@gmail.com> |
[clang-format] [PR35518] C++17 deduction guides are wrongly formatted
Summary: see https://bugs.llvm.org/show_bug.cgi?id=35518
clang-format removes spaces around deduction guides but not trailing r
[clang-format] [PR35518] C++17 deduction guides are wrongly formatted
Summary: see https://bugs.llvm.org/show_bug.cgi?id=35518
clang-format removes spaces around deduction guides but not trailing return types, make the consistent
``` template <typename T> S(T)->S<T>; auto f(int, int) -> double; ```
becomes
``` template <typename T> S(T) -> S<T>; auto f(int, int) -> double; ```
Reviewers: klimek, mitchell-stellar, owenpan, sammccall, lichray, curdeius, KyrBoh
Reviewed By: curdeius
Subscribers: merge_guards_bot, hans, lichray, cfe-commits
Tags: #clang-format, #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D69577
show more ...
|
#
8d7bd575 |
| 31-Oct-2019 |
Mitchell Balan <mitchell@stellarscience.com> |
[clang-format] Fix SpacesInSquareBrackets for Lambdas with Initial "&ref" Parameter
Summary: This fixes an edge case in the `SpacesInSquareBrackets` option where an initial `&ref` lambda parameter i
[clang-format] Fix SpacesInSquareBrackets for Lambdas with Initial "&ref" Parameter
Summary: This fixes an edge case in the `SpacesInSquareBrackets` option where an initial `&ref` lambda parameter is not padded with an initial space.
`int foo = [&bar ]() {}` is fixed to give `int foo = [ &bar ]() {}`
Reviewers: MyDeveloperDay, klimek, sammccall
Reviewed by: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D69649
show more ...
|
#
7f704320 |
| 18-Oct-2019 |
Brian Gesiak <modocache@gmail.com> |
[Format] Add format check for throwing negative numbers
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 ch
[Format] Add format check for throwing negative numbers
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
llvm-svn: 375258
show more ...
|
#
eff2a2ab |
| 18-Oct-2019 |
Krasimir Georgiev <krasimir@google.com> |
[clang-format] fix regression recognizing casts in Obj-C calls
Summary: r373922 added checks for a few tokens that, following an `)` make it unlikely that the `)` is the closing paren of a cast expr
[clang-format] fix regression recognizing casts in Obj-C calls
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
llvm-svn: 375247
show more ...
|
#
3b4c8f68 |
| 10-Oct-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] throws an incorrect assertion in consumeToken() formatting the MSVC stl
Summary: An incorrect assertion is thrown when clang-formatting MSVC's STL library
``` Assertion failed: !Line
[clang-format] throws an incorrect assertion in consumeToken() formatting 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
llvm-svn: 374399
show more ...
|
#
ae1b7859 |
| 09-Oct-2019 |
Krasimir Georgiev <krasimir@google.com> |
[clang-format] Update noexcept reference qualifiers detection
Summary: r373165 fixed an issue where a templated noexcept member function with a reference qualifier would be indented more than expect
[clang-format] Update noexcept reference qualifiers detection
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
llvm-svn: 374172
show more ...
|
#
2c3f7380 |
| 07-Oct-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] [PR27004] omits leading space for noexcept when formatting operator delete()
Summary: clang-format is incorrectly thinking the parameter parens are part of a cast operation, this is r
[clang-format] [PR27004] omits leading space for noexcept when formatting 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
llvm-svn: 373922
show more ...
|
#
375a84bb |
| 05-Oct-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] SpacesInSquareBrackets should affect lambdas with parameters too
Summary: This patch makes the `SpacesInSquareBrackets` setting also apply to C++ lambdas with parameters.
Looking thr
[clang-format] SpacesInSquareBrackets should affect lambdas with parameters too
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
llvm-svn: 373821
show more ...
|
#
cccf5aa0 |
| 04-Oct-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] C++11 braced lists should respect the SpacesInParentheses setting
Summary: According to the clang-format documentation, "Fundamentally, C++11 braced lists are formatted exactly like f
[clang-format] C++11 braced lists should respect the SpacesInParentheses setting
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
llvm-svn: 373751
show more ...
|
#
ba12cec2 |
| 04-Oct-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] [PR43531] clang-format damages "alternative representations" for operators
Summary: https://bugs.llvm.org/show_bug.cgi?id=43531
Fix for clang-format incorrectly handles "alternative
[clang-format] [PR43531] clang-format damages "alternative representations" 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
llvm-svn: 373750
show more ...
|
#
a37a6dcd |
| 04-Oct-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] [PR42417] clang-format inserts a space after '->' for operator->() overloading
Summary: https://bugs.llvm.org/show_bug.cgi?id=42417
This revision removes the extra space between the
[clang-format] [PR42417] clang-format inserts a space after '->' for 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
llvm-svn: 373746
show more ...
|
#
fb13e65a |
| 03-Oct-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] Add ability to wrap braces after multi-line control statements
Summary: Change the BraceWrappingFlags' AfterControlStatement from a bool to an enum with three values:
* "Never": This
[clang-format] Add ability to wrap braces after multi-line control statements
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
llvm-svn: 373647
show more ...
|
#
e5032567 |
| 02-Oct-2019 |
Sam McCall <sam.mccall@gmail.com> |
[ClangFormat] Future-proof Standard option, allow floating or pinning to arbitrary lang version
Summary: The historical context: - clang-format was written when C++11 was current, and the main lan
[ClangFormat] Future-proof Standard option, allow floating or pinning to 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
llvm-svn: 373439
show more ...
|
#
83476b81 |
| 29-Sep-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] Reference qualifiers in member templates causing extra indentation.
Summary: The following code
``` struct f { template <class T> void bar() && noexcept {} }; ```
will be format
[clang-format] Reference qualifiers in member templates causing extra 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
llvm-svn: 373165
show more ...
|
#
4627bded |
| 27-Sep-2019 |
Ilya Biryukov <ibiryukov@google.com> |
Revert r373056: [clang-format] Reference qualifiers in member templates causing extra indentation
Reason: this breaks unit tests. llvm-svn: 373059
|
#
c5343e72 |
| 27-Sep-2019 |
Ilya Biryukov <ibiryukov@google.com> |
[clang-format] Reference qualifiers in member templates causing extra indentation
The following code
``` struct f { template <class T> void bar() && noexcept {} }; ```
will be formatted to the
[clang-format] Reference qualifiers in member templates causing extra 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
llvm-svn: 373056
show more ...
|
#
f0458283 |
| 26-Sep-2019 |
Fangrui Song <maskray@google.com> |
[clang-format] Add SortPriority fields to fix -Wmissing-field-initializers after D64695/r372919
llvm-svn: 372939
|
#
bce849e3 |
| 24-Sep-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format] NFC clang-format the clang-format unit tests
Summary: It is annoying that the clang-format tests aren't themselves clang-formatted, if you use a format on save option in VS or vim thi
[clang-format] NFC clang-format the clang-format unit tests
Summary: It is annoying that the clang-format tests aren't themselves clang-formatted, if you use a format on save option in VS or vim this file gets massively changed then you have to `git difftool` all the other changes back out, which is risky.
I know people don't like mass clang-format changes but sometimes it becomes unmanageable to not. There are no other changes here other than just the reformat.
clang-format tests all pass.
``` [==========] 691 tests from 21 test cases ran. (55990 ms total) [ PASSED ] 691 tests. ```
Reviewers: klimek, owenpan, timwoj
Reviewed By: owenpan
Subscribers: cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D67888
llvm-svn: 372689
show more ...
|
#
a506ed25 |
| 22-Sep-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
Clang-format: Add Whitesmiths indentation style
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 rewor
Clang-format: Add Whitesmiths indentation style
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
llvm-svn: 372497
show more ...
|
#
a767a068 |
| 18-Sep-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format][PR41899] PointerAlignment: Left leads to useless space in lambda intializer expression
Summary: https://bugs.llvm.org/show_bug.cgi?id=41899
```auto lambda = [&a = a]() { a = 2; };```
[clang-format][PR41899] PointerAlignment: Left leads to useless space in 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
llvm-svn: 372249
show more ...
|
#
79983be5 |
| 18-Sep-2019 |
Paul Hoad <mydeveloperday@gmail.com> |
[clang-format][PR41964] Fix crash with SIGFPE when TabWidth is set to 0 and line starts with tab
Summary: clang-format 8.0 crashes with SIGFPE (floating point exception) when formatting following fi
[clang-format][PR41964] Fix crash with SIGFPE when TabWidth is set to 0 and 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
llvm-svn: 372246
show more ...
|
#
41f4d68a |
| 13-Sep-2019 |
Nico Weber <nicolasweber@gmx.de> |
clang-format: Add support for formatting (some) lambdas with explicit template parameters.
This patch makes cases work where the lambda's template list doesn't contain any of + - ! ~ / % << | || &&
clang-format: Add support for formatting (some) lambdas with explicit 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
llvm-svn: 371854
show more ...
|