| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fixes #160775
|
|
Fixes #160518
|
|
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.
|
|
(#159140)
When the style is
`{AlignConsecutiveDeclarations: true, Cpp11BracedListStyle: false}`, the
program would sometimes align the lambda body with the outside. Like
this.
```C++
const volatile auto result{ []() {
const auto something = 1;
return 2;
} };
```
This patch stops it. Now the output looks like this.
```C++
const volatile auto result{ []() {
const auto something = 1;
return 2;
} };
```
Fixes #53699.
The problem was with how the `AlignTokenSequence` function tracked
levels. The stack was pushed once when a token was more nested than the
previous one. It was popped once when a token was less nested than the
previous one. With the option `Cpp11BracedListStyle` disabled, the `[`
token was deeper than the previous token by 2 levels. Both its
indentation level and nesting level were more than that of the previous
one. But the stack was only pushed once. The following tokens popped the
2 levels separately. The function treated the body of the lambda
expression as on the same level as the outside.
The problem is fixed this way. The function `AlignTokens` which calls
the function `AlignTokenSequence` already uses a simpler and more robust
way to track levels. It remembers the outermost level it should align.
It compares the token's level with the outermost level. It does not need
a stack. So it is immune to the problem. This patch makes the function
`AlignTokenSequence` take as a parameter the indices of the tokens
matched by the function `AlignTokens`. This way it does not have to
contain the logic again.
Now the function `AlignTokenSequence` only aligns tokens already matched
by the function `AlignTokens`. It is easy to see that the assertion on
line 453 holds. The workaround on line 354 is not needed any more. The
test on line 20310 added at the same time as the assertion ensures that
the assertion hold.
The stack in the function `AlignTokenSequence` is kept for now. It is
still used to figure out when things inside a level should move along
with the outer level. Since the stack has the problem, the developer
plans to move the logic into token annotator. It already uses a stack.
|
|
This in effect reverts 05fb8408de23c3ccb6125b6886742177755bd757 and
7e1a88b9d1431e263258e3ff0f729c1fdce342d3, the latter of which
erroneously changed the behavior of formatting `ObjC` header files when
both the default and `ObjC` styles were absent. Now the previous
behavior of treating that as an error is restored.
Fixes #158704
|
|
The test cases are adapted from #131605.
|
|
|
|
Fixes #158413
|
|
Allow an option to leave preprocessor directive indenting as-is. This
simplifies handling mixed styles of CPP directive indentation.
Fixes #38511
|
|
Some languages have the flexibility to use upper or lower case
characters interchangeably in integer and float literal definitions.
I'd like to be able to enforce a consistent case style in one of my
projects, so I added this clang-format style option to control it.
With this .clang-format configuration:
```yaml
NumericLiteralCaseStyle:
UpperCasePrefix: Never
UpperCaseHexDigit: Always
UpperCaseSuffix: Never
```
This line of code:
```C
unsigned long long 0XdEaDbEeFUll;
```
gets reformatted into this line of code:
```C
unsigned long long 0xDEAFBEEFull;
```
-----
I'm new to this project, so please let me know if I missed something in
the process. I modeled this PR from
[IntegerLiteralSeparatorFixer](https://reviews.llvm.org/D140543)
|
|
Fixes https://github.com/llvm/llvm-project/issues/154634.
Allow inserting space before DAGArg's opener paren when nested.
|
|
Fix #145161
|
|
Fixes #155746
|
|
All comments before the macro definition body should be skipped.
|
|
Fixes #154683
|
|
Also set it to SIEB_Always for WebKit style.
Closes #85525.
Closes #93635.
|
|
Fixes #153891
|
|
Fixes #153448
|
|
Fixes #153443
|
|
(#152878)
|
|
Also make a StringRef literal `static constexpr`.
|
|
Fixes #151102
|
|
This effectively reverts a4d4859dc70c046ad928805ddeaf8fa101793394 which
didn't fix the problem that `int*,` was not counted as "Left" alignment.
Fixes #150327
|
|
The [Google C++ Style
Guide](https://google.github.io/styleguide/cppguide.html#Pointer_and_Reference_Expressions)
is being changed to specify that spaces should go after the
asterisk/ampersand, rather than permitting either before or after on a
file-by-file basis.
The new requirement is:
> When referring to a pointer or reference (variable declarations or
> definitions, arguments, return types, template parameters, etc.),
> you must not place a space before the asterisk/ampersand. Use a
> space to separate the type from the declared name (if present).
The [Google ObjC
style](https://google.github.io/styleguide/objcguide.html) is silent on
this matter, but the de-facto style is not being modified at this time.
So, keep DerivePointerAlignment enabled for ObjC language mode.
|
|
Fixes #150327
|
|
Closes #149971
|
|
The colon in a constructor's initializer list triggers the inlining of a
nested block as if it was a conditional operator expression. This
prevents line breaks under certain circumstances when the initializer
list contains braced initializers, which in turn prevents the line
formatter from finding a solution.
In this commit we exclude colons that are a constructor initializer
colon from consideration of nested block inlining.
Fixes #97242.
Fixes #81822.
|
|
Consistently use `constexpr StringRef Code("string literal");`.
|
|
When reviewing #147156, the reviewers pointed out that we didn't need to
support the trigraph. The code never handled it right.
In the debug build, this kind of input caused the assertion in the
function `countLeadingWhitespace` to fail. The release build without
assertions outputted `?` `?` `/` separated by spaces.
```C
#define A ??/
int i;
```
This is because the code in `countLeadingWhitespace` assumed that the
underlying lexer recognized the entire `??/` sequence as a single token.
In fact, the lexer recognized it as 3 separate tokens. The flag to make
the lexer recognize trigraphs was never enabled.
This patch enables the flag in the underlying lexer. This way, the
program now either turns the trigraph into a single `\` or removes it
altogether if the line is short enough. There are operators like the
`??=` in C#. So the flag is not enabled for all input languages. Instead
the check for the token size is moved from the assert line into the if
line.
The problem was introduced by my own patch 370bee480139 from about 3
years ago. I added code to count the number of characters in the escape
sequence probably just because the block of code used to have a comment
saying someone should add the feature. Maybe I forgot to enable
assertions when I ran the code. I found the problem because reviewing
pull request 145243 made me look at the code again.
|
|
Fixes #149520
|
|
Fixes #149010
|
|
Sorting by stem gives nicer results when various header file names are
substrings of other header file names. For example, a CLI application
with a main header named analyze.h and an analyze-xxx.h header for each
subcommand currently will always put analyze.h last after all the
analyze-xxx.h headers, but putting analyze.h first instead is arguably
nicer to read.
TLDR; Instead of
```
#include "analyze-blame.h"
#include "analyze.h"
```
You'd get
```
#include "analyze.h"
#include "analyze-blame.h"
```
Let's allow sorting by stem instead of full path by adding
IgnoreExtension to SortIncludes.
|
|
|
|
This allows RemoveParentheses to skip the invocations of function-like
macros.
Fixes #68354.
Fixes #147780.
|
|
|
|
Fixes #147341
|
|
|
|
with std::numeric_limits (#147623)
This PR addresses instances of compiler warning C4146 that can be
replaced with std::numeric_limits. Specifically, these are cases where a
literal such as '-1ULL' was used to assign a value to a uint64_t
variable. The intent is much cleaner if we use the appropriate
std::numeric_limits value<Type>::max() for these cases.
Addresses #147439
|
|
|
|
|
|
(#146761)
Before this commit, when `LineJoiner` joins a line with affected leading
whitespace, it would drop the knowledge of this entirely. However, when
the `AffectedRangeManager` is computing the affected lines, the leading
empty whitespace lines are potentially considered for non-first tokens
in the `AnnotatedLine`. This causes a discrepancy in behavior when an
`AnnotatedLine` is put together from joining multiple lines versus when
it is not.
We change `LineJoiner::join` to follow `AffectedRangeManager`'s logic,
considering the leading whitespace when determining `Affected` for a
token.
https://github.com/llvm/llvm-project/blob/a63f57262898588b576d66e5fd79c0aa64b35f2d/clang/lib/Format/AffectedRangeManager.cpp#L111-L130
Fixes #138942.
|
|
|
|
Fixes #39150
|
|
This was done before in https://reviews.llvm.org/D46320
|
|
Missed by #145686
|
|
(#145243)
Fixes #145226.
Implement
[P2223R2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2223r2.pdf)
in clang-format to correctly handle cases where a backslash '\\' is
followed by trailing whitespace before the newline.
Previously, `clang-format` failed to properly detect and handle such
cases, leading to misformatted code.
With this, `clang-format` matches the behavior already implemented in
Clang's lexer and `DependencyDirectivesScanner.cpp`, which allow
trailing whitespace after a line continuation in any C++ standard.
|
|
At the start of the case for `tok::colon`, we do an early return if
`Prev` is null. Nothing else within that case modifies the value of
`Prev`, so the checks for null are unnecessary and were confusing
static analysis tools.
|
|
Fixes #145388
|
|
See also
https://github.com/llvm/llvm-project/pull/141576/files#r2141808121
|
|
Stop looking for function decls after hitting a BK_BracedInit brace.
Fixes #144057.
|
