| Age | Commit message (Collapse) | Author |
|---|
|
Fixes #154846
|
|
Lines appearing after preprocessor conditional blocks (like `#endif`)
were not having their qualifiers reordered by `QualifierOrder`, while
lines inside the conditional blocks were processed correctly.
The issue was that tokens on lines following preprocessor directives
have `MustBreakBefore` = `true`. The qualifier alignment logic was
breaking immediately upon encountering any token with `MustBreakBefore`
= `true`, preventing analysis of the entire line.
The fix allows processing to continue when `MustBreakBefore` = `true` on
the first token of a line, since this is expected behavior (the token
legitimately starts a new line). Only tokens with `MustBreakBefore` =
`true` that appear mid-line will cause the analysis loop to break.
Fixes https://github.com/llvm/llvm-project/issues/160487.
|
|
Fixes #145388
|
|
Fixes #125178.
|
|
Fixes #123573.
|
|
Fixes #120793.
|
|
Also, don't insert a space after ::* for method pointers.
See
https://github.com/llvm/llvm-project/pull/86253#issuecomment-2298404887.
Fixes #100841.
|
|
|
|
Remove FormatToken::isSimpleTypeSpecifier() and call
Token::isSimpleTypeSpecifier(LangOpts) instead.
|
|
|
|
Move static member functions LeftRightQualifierAlignmentFixer::is...()
out of the class so that #91712 can reland.
|
|
This reverts commits e62ce1f8842c, 5cd280433e8e, and de641e289269 due to
buildbot failures.
|
|
Fix the following buildbot failures by making LangOpts in the unit test
static:
https://lab.llvm.org/buildbot/#/builders/236/builds/11223
https://lab.llvm.org/buildbot/#/builders/239/builds/6968
|
|
This reverts commit 0869204cff22831d0bb19a82c99bf85e4deb4ae3, which caused a
buildbot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/43322
|
|
This effectively reverts 5cd280433e8e and changes to QualifierFixerTest.cpp
from e62ce1f8842c.
Failed buidbots:
https://lab.llvm.org/buildbot/#/builders/236/builds/11223
https://lab.llvm.org/buildbot/#/builders/239/builds/6968
|
|
This should fix buildbot failures in:
https://lab.llvm.org/buildbot/#/builders/5/builds/43303
https://lab.llvm.org/buildbot/#/builders/168/builds/20347
|
|
Remove FormatToken::isSimpleTypeSpecifier() and call
Token::isSimpleTypeSpecifier(LangOpts) instead.
|
|
Fixes #85761.
|
|
Fixes #80579.
|
|
|
|
This reverts commit 173e674ba55eb93e8af43f2eece7feffe9954b34.
Actually, NotTokens[5] in QualifierFixerTest.cpp is not out of bounds.
|
|
|
|
Fixed #62780.
|
|
Fixed #69610.
|
|
Also removed a duplicate test case.
|
|
Fix file mode errors introduced in 2c9372e78d7c and format errors in
https://reviews.llvm.org/D155239.
|
|
This fixes github issue #57117: If the "QualifierAlignment"
option of clang-format is set to anything else but "Leave", the
"QualifierAlignmentFixer" pass gets enabled. This pass scales
quadratically with the number of preprocessor branches, i.e.
with the number of elements in TokenAnalyzer::UnwrappedLines.
The reason is that QualifierAlignmentFixer::process() generates
the UnwrappedLines, but then QualifierAlignmentFixer::analyze()
calls LeftRightQualifierAlignmentFixer::process() several times
(once for each qualifier) which again each time generates the
UnwrappedLines.
This commit gets rid of this double loop by registering the
individual LeftRightQualifierAlignmentFixer passes directly in
the top most container of passes (local variable "Passes" in
reformat()).
With this change, the original example in the github issue #57117
now takes only around 3s instead of >300s to format.
Since QualifierAlignmentFixer::analyze() got deleted, we also
no longer have the code with the NonNoOpFixes. This causes
replacements that end up not changing anything to appear in the
list of final replacements. There is a unit test to check that
this does not happen: QualifierFixerTest.NoOpQualifierReplacements.
However, it got broken at some point in time. So this commit
fixes the test. To keep the behavior that no no-op replacements
should appear from the qualifier fixer, the corresponding code
from QualifierAlignmentFixer::analyze() was moved to the top
reformat() function. Thus, is now done for **every** replacement
of every formatting pass. If no-op replacements are a problem
for the qualifier fixer, then it seems to be a good idea to
filter them out always.
See
https://github.com/llvm/llvm-project/issues/57117#issuecomment-1546716934
for some more details.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D153228
|
|
This patch adds a verifyNoChange macro to verify code that won't
change after being formatted. (The code will not be messed up before
being formatted.) It then replaces EXPECT_EQ with verifyFormat
wherever applicable so that the code will be messed up before being
formatted. When the replacement fails the unit test, verifyFormat is
replaced with verifyNoChange.
Differential Revision: https://reviews.llvm.org/D153109
|
|
alignment
The qualifier alignment fixer appeared to ignore any ranges specified for limiting formatting.
This change ensures that it only formats affected lines to avoid unexpected changes.
Fixes #54888.
Differential Revision: https://reviews.llvm.org/D149643
|
|
Qualifiers were not moved for non-pointer non-simple types.
Add additional support for many special cases such as templates,
requires clauses, long qualified names.
Fixes https://github.com/llvm/llvm-project/issues/57154 and
https://github.com/llvm/llvm-project/issues/60898
Reviewed By: MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D144709
|
|
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.
|
|
Previously, given a pointer-to-member type such as `Foo const Bar::*`,
clang-format would see the `const Bar::` part as a regular type name
with scope resolution operators, and with `QualifierAlignment: Right` it
would attempt to "fix" it, resulting in `Foo Bar::const *`, a syntax
error.
This patch no longer allows qualifiers to be moved across `::*`.
Fixes https://github.com/llvm/llvm-project/issues/60898
Reviewed By: owenpan, MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D144537
|
|
For cases of defining friend functions, qualifier ordering can
allow multiple positions for the 'friend' token.
Closes #59450.
Differential Revision: https://reviews.llvm.org/D139801
|
|
Fixes https://github.com/llvm/llvm-project/issues/55610.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D126096
|
|
Related to #54513.
|
|
Fixes #54513
Differential Revision: https://reviews.llvm.org/D122548
|
|
https://github.com/llvm/llvm-project/issues/53981
Reorder the qualifiers inside the template argument. This should handle the simple cases of
```
<const T>
<T const>
```
But only by relaxing that single letter capital variables are not possible macros
Fixes: #53981
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D120710
|
|
Fixes https://github.com/llvm/llvm-project/issues/53962.
Given the config:
```
BasedOnStyle: LLVM
QualifierAlignment: Custom
QualifierOrder: ['constexpr', 'type']
```
The code:
```
template <typename F>
requires std::invocable<F>
constexpr constructor();
```
was incorrectly formatted to:
```
template <typename F>
requires
constexpr std::invocable<F> constructor();
```
because we considered `std::invocable<F> constexpr` as a type, not recognising the requires clause.
This patch avoids moving the qualifier across the boundary of the requires clause (checking `ClosesRequiresClause`).
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D120309
|
|
Fixes https://github.com/llvm/llvm-project/issues/53643.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D119218
|
|
template closer is null
https://github.com/llvm/llvm-project/issues/53008
```
template <class Id> using A = quantity /**/<kind<Id>, 1>;
```
the presence of the comment between identifier and template opener seems to be causing the qualifier alignment to fail
Reviewed By: curdeius
Fixes: #53008
Differential Revision: https://reviews.llvm.org/D116726
|
|
replacements when they don't actually change anything
Earlier during the development of {D69764} I felt it was no longer necessary to
ensure we were not trying to change code which didn't need to change
and we felt this could be removed, however I'd like to bring this back for now
as I am seeing some false positives in terms of the "replacements"
What I see is the generation of a replacement which is a "No Op" on the original
code, I think this comes about because of the merging of replacements:
```
static const a;
->
const static a;
->
static const a;
```
The replacements don't really merge, in such a way as to identify when we have gone
back to the original
Also remove the Penalty as I'm not using it (and it became marked as set and no used,
I'd rather get rid of it if it means nothing)
I think we need to do this step for now, as many people use the --output-replacements-xml
to identify that the file "needs a clang-format"
The same can be seen with the -n or --dry-run option as this uses the replacements
to drive the error/warning output.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D110392
|
|
Commit a44ab1702539 added a unit test that fails to build with
-Werror which causes build bot breaks on bots that include that
option in their build. This patch just adds the necessary casts to
silence the warnings.
|
|
Developers these days seem to argue over east vs west const like they used to argue over tabs vs whitespace or the various bracing style. These previous arguments were mainly eliminated with tools like `clang-format` that allowed those rules to become part of your style guide. Anyone who has been using clang-format in a large team over the last couple of years knows that we don't have those religious arguments any more, and code reviews are more productive.
https://www.youtube.com/watch?v=fv--IKZFVO8
https://mariusbancila.ro/blog/2018/11/23/join-the-east-const-revolution/
https://www.youtube.com/watch?v=z6s6bacI424
The purpose of this revision is to try to do the same for the East/West const discussion. Move the debate into the style guide and leave it there!
In addition to the new `ConstStyle: Right` or `ConstStyle: Left` there is an additional command-line argument `--const-style=left/right` which would allow an individual developer to switch the source back and forth to their own style for editing, and back to the committed style before commit. (you could imagine an IDE might offer such a switch)
The revision works by implementing a separate pass of the Annotated lines much like the SortIncludes and then create replacements for constant type declarations.
Differential Revision: https://reviews.llvm.org/D69764
|
