History log of /llvm-project/clang/unittests/Format/FormatTest.cpp (Results 176 – 200 of 2034)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 4b976495 02-Jun-2023 Owen Pan <owenpiano@gmail.com>

[clang-format] Fix overlapping replacements before PPDirectives

If the first token of an annotated line is finalized, reuse its
NewlinesBefore value to avoid potential overlapping whitespace
replace

[clang-format] Fix overlapping replacements before PPDirectives

If the first token of an annotated line is finalized, reuse its
NewlinesBefore value to avoid potential overlapping whitespace
replacements before preprocessor branching directives.

Fixes #62892.

Differential Revision: https://reviews.llvm.org/D151954

show more ...


# d39929b9 23-May-2023 Galen Elias <galenelias@gmail.com>

[clang-format] Adjust braced list detection (reland 6dcde65)

This is a retry of https://reviews.llvm.org/D114583, which was backed
out for regressions.

Clang Format is detecting a nested scope foll

[clang-format] Adjust braced list detection (reland 6dcde65)

This is a retry of https://reviews.llvm.org/D114583, which was backed
out for regressions.

Clang Format is detecting a nested scope followed by another open brace
as a braced initializer list due to incorrectly thinking it's matching a
braced initializer at the end of a constructor initializer list which is
followed by the body open brace.

Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so
it's not super straightforward to distinguish these cases given the
current structure of calculateBraceTypes. My current hypothesis is that
these can be disambiguated by looking at the token preceding the
l_brace, as initializer list parameters will be preceded by an
identifier, but a scope block generally will not (barring the MACRO
wildcard).

To this end, I am adding tracking of the previous token to the LBraceStack
to help scope this particular case.

TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452.

Fixes #33891.
Fixes #52911.

Differential Revision: https://reviews.llvm.org/D150403

show more ...


# dc4ab970 24-May-2023 Owen Pan <owenpiano@gmail.com>

[clang-format] Revert 6dcde65 due to missing commit message title

This reverts commit 6dcde658b2380d7ca1451ea5d1099af3e294ea16.


# 6dcde658 23-May-2023 Galen Elias <galenelias@gmail.com>

This is a retry of https://reviews.llvm.org/D114583, which was backed
out for regressions.

Clang Format is detecting a nested scope followed by another open brace
as a braced initializer list due to

This is a retry of https://reviews.llvm.org/D114583, which was backed
out for regressions.

Clang Format is detecting a nested scope followed by another open brace
as a braced initializer list due to incorrectly thinking it's matching a
braced initializer at the end of a constructor initializer list which is
followed by the body open brace.

Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so
it's not super straightforward to distinguish these cases given the
current structure of calculateBraceTypes. My current hypothesis is that
these can be disambiguated by looking at the token preceding the
l_brace, as initializer list parameters will be preceded by an
identifier, but a scope block generally will not (barring the MACRO
wildcard).

To this end, I am adding tracking of the previous token to the LBraceStack
to help scope this particular case.

TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452.

Fixes #33891.
Fixes #52911.

Differential Revision: https://reviews.llvm.org/D150403

show more ...


# 06763ea5 18-May-2023 Emilia Kond <emilia@rymiel.space>

[clang-format] Ignore first token when finding MustBreak

When in ColumnLimit 0, the formatter looks for MustBreakBefore in the
line in order to check if a line is allowed to be merged onto one line.

[clang-format] Ignore first token when finding MustBreak

When in ColumnLimit 0, the formatter looks for MustBreakBefore in the
line in order to check if a line is allowed to be merged onto one line.

However, since MustBreakBefore is really a property of the gap between
the token and the one previously, I belive the check is erroneous in
checking all the tokens in a line, since whether the previous line ended
with a forced line break should have no effect on whether the current
line is allowed to merge with the next one.

This patch changes the check to skip the first token in
`LineJoiner.containsMustBreak`.

This patch also changes a test, which is not ideal, but I believe the
test also suffered from this bug. The test case in question sets
AllowShortFunctionsOnASingleLine to "Empty", but the empty function in
said test case isn't merged to a single line, because of the very same
bug this patch fixes.

Fixes https://github.com/llvm/llvm-project/issues/62721

Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D150614

show more ...


# e4d3e888 16-May-2023 Emilia Kond <emilia@rymiel.space>

[clang-format] Don't allow template to be preceded by closing brace

This check is similar to the right paren check right below it, but it
doesn't need the overloaded operator check.

This patch prev

[clang-format] Don't allow template to be preceded by closing brace

This check is similar to the right paren check right below it, but it
doesn't need the overloaded operator check.

This patch prevents brace-initialized objects that are being compared
from being mis-annotated as template parameters.

Fixes https://github.com/llvm/llvm-project/issues/57004

Reviewed By: owenpan, MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D150629

show more ...


# a4c87f8c 06-May-2023 Owen Pan <owenpiano@gmail.com>

[clang-format] Fix consecutive alignments in #else blocks

Since 3.8 or earlier, clang-format has been lumping all #else, #elif,
etc blocks together when doing whitespace replacements and causing
con

[clang-format] Fix consecutive alignments in #else blocks

Since 3.8 or earlier, clang-format has been lumping all #else, #elif,
etc blocks together when doing whitespace replacements and causing
consecutive alignments across #else blocks.

Commit c077975 partially addressed the problem but also triggered
"regressions".

This patch fixes the root cause of the problem and "reverts" c077975
(except for the unit tests).

Fixes #36070.
Fixes #55265.
Fixes #60721.
Fixes #61498.

Differential Revision: https://reviews.llvm.org/D150057

show more ...


# 82a90caa 30-Apr-2023 sstwcw <f0gukp2nk@protonmail.com>

[clang-format] Correctly format goto labels followed by blocks

There doesn't seem to be an issue on GitHub. But previously, a space
would be inserted before the goto colon in the code below.

s

[clang-format] Correctly format goto labels followed by blocks

There doesn't seem to be an issue on GitHub. But previously, a space
would be inserted before the goto colon in the code below.

switch (x) {
case 0:
goto_0: {
action();
break;
}
}

Previously, the colon following a goto label would be annotated as
`TT_InheritanceColon`. A goto label followed by an opening brace
wasn't recognized. It is easy to add another line to have
`spaceRequiredBefore` function recognize the case, but I believed it
is more proper to avoid doing the same thing in `UnwrappedLineParser`
and `TokenAnnotator`. So now the label colons would be labeled in
`UnwrappedLineParser`, and `spaceRequiredBefore` would rely on that.

Previously we had the type `TT_GotoLabelColon` intended for both goto
labels and case labels. But since handling of goto labels and case
labels differ somewhat, I split it into separate types for goto and
case labels.

This patch doesn't change the behavior for case labels. I added the
lines annotating case labels because they would previously be
mistakenly annotated as `TT_InheritanceColon` just like goto labels.
And since I added the annotations, the checks for the `case` and
`default` keywords in `spaceRequiredBefore` are not necessary anymore.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D148484

show more ...


# c12aa69a 29-Apr-2023 Jon Phillips <jonap2811@gmail.com>

[clang-format] Add BracedInitializerIndentWidth option

The option allows users to specify how many columns to use to indent
the contents of initializer lists.

Closes #51070.

Differential Revision:

[clang-format] Add BracedInitializerIndentWidth option

The option allows users to specify how many columns to use to indent
the contents of initializer lists.

Closes #51070.

Differential Revision: https://reviews.llvm.org/D146101

show more ...


# 9db2a045 16-Apr-2023 Jorge Pinto Sousa <jorge.pinto.sousa@proton.me>

[clang-format] Dont interpret variable named interface as keyword for C++

Fixes #53173.

Differential Revision: https://reviews.llvm.org/D148437


# 5c614bd8 05-Apr-2023 Jon Phillips <jonap2811@gmail.com>

[clang-format] Fix bugs with "LambdaBodyIndentation: OuterScope"

The previous implementation of the option corrupted the parenthesis
state stack. (See https://reviews.llvm.org/D102706.)

Fixes #5570

[clang-format] Fix bugs with "LambdaBodyIndentation: OuterScope"

The previous implementation of the option corrupted the parenthesis
state stack. (See https://reviews.llvm.org/D102706.)

Fixes #55708.
Fixes #53212.
Fixes #52846.
Fixes #59954.

Differential Revision: https://reviews.llvm.org/D146042

show more ...


# 1dd31ebe 02-Apr-2023 Jon Phillips <jonap2811@gmail.com>

[clang-format][NFC] Refactor unit tests for "LambdaBodyIndentation: OuterScope"

Differential Revision: https://reviews.llvm.org/D146995


# 767aee1d 26-Mar-2023 Owen Pan <owenpiano@gmail.com>

[clang-format] Don't annotate left brace of struct as FunctionLBrace

Related to a02c3af9f19d. Fixes #61700.

Differential Revision: https://reviews.llvm.org/D146895


# a8d2bff2 26-Mar-2023 Emilia Dreamer <emilia@rymiel.space>

[clang-format] Don't wrap struct return types as structs

When using BraceWrapping.AfterClass or BraceWrapping.AfterStruct, the
token annotator relies on the first token of the line to determine if
w

[clang-format] Don't wrap struct return types as structs

When using BraceWrapping.AfterClass or BraceWrapping.AfterStruct, the
token annotator relies on the first token of the line to determine if
we're dealing with a struct or class, however, this check is faulty if
it's actually a function with an elaborated struct/class return type, as
is common in C.

This patch skips the check if the brace is already annotated as
FunctionLBrace, in which case we already know it's a function and should
be treated as such.

Fixes https://github.com/llvm/llvm-project/issues/58527

Reviewed By: HazardyKnusperkeks, owenpan

Differential Revision: https://reviews.llvm.org/D146281

show more ...


# c70e360b 23-Mar-2023 Emilia Dreamer <emilia@rymiel.space>

[clang-format] Allow trailing return types in macros

The trailing return type arrow checker verifies that a declaration is
being parsed, however, this isn't true when inside of macros.

It turns out

[clang-format] Allow trailing return types in macros

The trailing return type arrow checker verifies that a declaration is
being parsed, however, this isn't true when inside of macros.

It turns out the existence of the auto keyword is enough to make
sure that we're dealing with a trailing return type, and whether we're
in a declaration doesn't matter.

Fixes https://github.com/llvm/llvm-project/issues/47664

Reviewed By: HazardyKnusperkeks, owenpan

Differential Revision: https://reviews.llvm.org/D141811

show more ...


# ead96446 22-Mar-2023 Emilia Dreamer <emilia@rymiel.space>

[clang-format] Annotate noexcept, explicit specifiers as containing expressions

The noexcept specifier and explicit specifier can optionally include a
boolean expression to make these specifiers app

[clang-format] Annotate noexcept, explicit specifiers as containing expressions

The noexcept specifier and explicit specifier can optionally include a
boolean expression to make these specifiers apply conditionally,
however, clang-format didn't set the context for the parenthesized
content of these specifiers, meaning they inherited the parent context,
which usually isn't an expressions, leading to misannotated binary
operators.

This patch applies expression context to the content of these
specifiers, making them similar to the static_assert keyword.

Fixes https://github.com/llvm/llvm-project/issues/44543

Reviewed By: owenpan, MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D146284

show more ...


# 682808d9 10-Feb-2023 Owen Pan <owenpiano@gmail.com>

Reland [clang-format] Add a space between an overloaded operator and '>'

The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This caus

Reland [clang-format] Add a space between an overloaded operator and '>'

The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This causes the
space between the operator and the closer to be removed, resulting
in invalid C++ code.

Fixes #58602.

Differential Revision: https://reviews.llvm.org/D143755

show more ...


# 696f8b32 20-Mar-2023 Kadir Cetinkaya <kadircet@google.com>

Revert "[clang-format] Add a space between an overloaded operator and '>'"

This reverts commit b05dc1b8766a47482cae432011fd2faa04c83a3e.

Makes clang-format crash on `struct Foo { operator enum foo{

Revert "[clang-format] Add a space between an overloaded operator and '>'"

This reverts commit b05dc1b8766a47482cae432011fd2faa04c83a3e.

Makes clang-format crash on `struct Foo { operator enum foo{} };`

show more ...


# c9163901 14-Mar-2023 Emilia Dreamer <emilia@rymiel.space>

[clang-format] Treat &/&& as reference when followed by requires clause

Previously, the token annotator would get confused and annotate a member
function's ref qualifier as a binary operator, if sai

[clang-format] Treat &/&& as reference when followed by requires clause

Previously, the token annotator would get confused and annotate a member
function's ref qualifier as a binary operator, if said function also had
a requires clause after it.

This patch accounts for that, treating requires clauses more similarly
to `noexcept`, which also comes after the ref qualifier.

Fixes https://github.com/llvm/llvm-project/issues/61270

Reviewed By: HazardyKnusperkeks, owenpan

Differential Revision: https://reviews.llvm.org/D145656

show more ...


# a02c3af9 06-Mar-2023 Owen Pan <owenpiano@gmail.com>

[clang-format] Don't annotate left brace of class as FunctionLBrace

The l_brace of class/struct/union was incorrectly annotated as
TT_FunctionLBrace in the presence of attributes. This in turn
would

[clang-format] Don't annotate left brace of class as FunctionLBrace

The l_brace of class/struct/union was incorrectly annotated as
TT_FunctionLBrace in the presence of attributes. This in turn
would cause the RemoveSemicolon option to remove the semicolon
at the end of the declaration, resulting in invalid code being
generated.

Fixes #61188.

Differential Revision: https://reviews.llvm.org/D145344

show more ...


# f8d10d5a 01-Mar-2023 Manuel Klimek <klimek@google.com>

[clang-format][NFC] Refactor formatting unit tests.

Pull out common base class for formatting unit tests, removing duplicate
code that accumulated over the years.

Pull out macro expansion test into

[clang-format][NFC] Refactor formatting unit tests.

Pull out common base class for formatting unit tests, removing duplicate
code that accumulated over the years.

Pull out macro expansion test into its own test file.

show more ...


# 466b4327 27-Feb-2023 Joseph Huber <jhuber6@vols.utk.edu>

[clang-format] Only add pragma continuation indentation for 'omp' clauses

The patch in D136100 added custom handling for pragmas to assist in
formatting OpenMP clauses correctly. One of these change

[clang-format] Only add pragma continuation indentation for 'omp' clauses

The patch in D136100 added custom handling for pragmas to assist in
formatting OpenMP clauses correctly. One of these changes added extra
indentation. This is desirable for OpenMP pragmas as they are several
complete tokens that would otherwise we on the exact same line. However,
this is not desired for the other pragmas.

This solution is extremely hacky, I'm not overly familiar with the
`clang-format` codebase. A better solution would probably require
actually parsing these as tokens, but I just wanted to propose a
solution.

Fixes https://github.com/llvm/llvm-project/issues/59473

Reviewed By: HazardyKnusperkeks

Differential Revision: https://reviews.llvm.org/D144884

show more ...


# 7ba91016 25-Feb-2023 Emilia Dreamer <emilia@rymiel.space>

[clang-format] Rewrite how indent is reduced for compacted namespaces

The previous version set the indentation directly using IndentForLevel,
however, this has a few caveats, namely:

* IndentForLev

[clang-format] Rewrite how indent is reduced for compacted namespaces

The previous version set the indentation directly using IndentForLevel,
however, this has a few caveats, namely:

* IndentForLevel applies to all scopes of the entire program being
formatted, but this indentation should only be adjusted for scopes
of namespaces.

* The method it used only set the correct indent amount if one wasn't
already set for a given level, meaning it didn't work correctly if
anything with indentation preceded a namespace keyword. This
includes preprocessing directives if using IndentPPDirectives.

This patch instead reduces the Level of all lines within namespaces
which are compacted by CompactNamespaces. This means they will get
correct indentation using the normal process.

Fixes https://github.com/llvm/llvm-project/issues/60843

Reviewed By: owenpan, MyDeveloperDay, HazardyKnusperkeks

Differential Revision: https://reviews.llvm.org/D144296

show more ...


# 01402831 01-Feb-2023 Manuel Klimek <klimek@google.com>

[clang-format] Add simple macro replacements in formatting.

Add configuration to specify macros.
Macros will be expanded, and the code will be parsed and annotated
in the expanded state. In a second

[clang-format] Add simple macro replacements in formatting.

Add configuration to specify macros.
Macros will be expanded, and the code will be parsed and annotated
in the expanded state. In a second step, the formatting decisions
in the annotated expanded code will be reconstructed onto the
original unexpanded macro call.

Eventually, this will allow to remove special-case code for
various macro options we accumulated over the years in favor of
one principled mechanism.

Differential Revision: https://reviews.llvm.org/D144170

show more ...


# b05dc1b8 10-Feb-2023 Owen Pan <owenpiano@gmail.com>

[clang-format] Add a space between an overloaded operator and '>'

The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This causes the

[clang-format] Add a space between an overloaded operator and '>'

The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This causes the
space between the operator and the closer to be removed, resulting
in invalid C++ code.

Fixes #58602.

Differential Revision: https://reviews.llvm.org/D143755

show more ...


12345678910>>...82