History log of /llvm-project/clang/unittests/Format/FormatTest.cpp (Results 576 – 600 of 2034)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1...<<21222324252627282930>>...82