| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
llvm::min_elements allows us to pass a range.
|
|
See
https://github.com/llvm/llvm-project/issues/65400#issuecomment-2922181979.
|
|
|
|
Similar to #142104
|
|
Fix #142818
|
|
Fix #142178
|
|
This reverts commit 29f79ea3c59649f7686a09845665660c25ca3f9b which caused a regression.
See https://github.com/llvm/llvm-project/pull/142251#issuecomment-2928718530.
|
|
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
|
|
Fix #142178
|
|
Fix #142050
|
|
|
|
Fix #137792
|
|
|
|
Fix #61954
|
|
|
|
|
|
|
|
Fix #65400
|
|
This allows adding other suboptions e.g. IgnoreExtension in #137840.
|
|
Fix #62356
|
|
Fix #139510
|
|
|
