| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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)
|
|
Also set it to SIEB_Always for WebKit style.
Closes #85525.
Closes #93635.
|
|
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
|
|
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.
|
|
|
|
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
|
|
|
|
Fix #137792
|
|
Fix #65400
|
|
This allows adding other suboptions e.g. IgnoreExtension in #137840.
|
|
|
|
Add SpaceAfterOperatorKeyword option to clang-format
|
|
|
|
This reverts commit b8bb1ccb4f9126d1bc9817be24e17f186a75a08b which triggered
an assertion failure in CodeGenTest.TestNonAlterTest.
|
|
Close #54334
|
|
|
|
Fix #135819
|
|
Fix #133135
|
|
Also remove redundant name qualifiers format::, FormatStyle::, and
LanguageKind::.
|
|
Fixes #110727
|
|
This allows simplification of code that checks if a token is an
Objective-C keyword.
Also, delete the following in
UnwrappedLineParser::parseStructuralElement():
- an else-after-break in the tok::at case
- the copypasted code in the tok::objc_autoreleasepool case
|
|
Fix #134453
|
|
Also refactor the code that removes/replaces a token.
|
|
Fix #132832
|
|
Add support for formatting w/ absl nullability macros
(https://github.com/abseil/abseil-cpp/blob/c52afac4f87ef76e6293b84874e5126a62be1f15/absl/base/nullability.h#L237).
Example at https://godbolt.org/z/PYv19M1Gj
input:
```
std::vector<int* _Nonnull> x;
std::vector<int* absl_nonnull> y;
```
orig output:
```
std::vector<int* _Nonnull> x;
std::vector<int * absl_nonnull> y;
```
new output:
```
std::vector<int* _Nonnull> x;
std::vector<int* absl_nonnull> y;
```
credit to @ymand for the original patch
|
|
Fix #128847
|
|
Fixes #106194
|
|
Fixes #108526
|
|
Closes #128120
|
|
Closes #128119
|
|
The use of Cpp11BracedListStyle with BinPackArguments=False avoids bin
packing until reaching a hard-coded limit of 20 items. This is an
arbitrary choice. Introduce a new style option to allow disabling this
limit.
|
|
In clang-format, multiline templates have the `>` on the same line as
the last parameter:
```c++
template <
typename Foo,
typename Bar>
void foo() {
```
I would like to add an option to put the `>` on the next line, like
this:
```c++
template <
typename Foo,
typename Bar
>
void foo() {
```
An example of a large project that uses this style is NVIDIA's CUTLASS,
here is an example:
https://github.com/NVIDIA/cutlass/blob/main/include/cutlass/epilogue/dispatch_policy.hpp#L149-L156
My reasoning is that it reminds me of this style of braces:
```c++
if (foo()) {
bar();
baz();}
```
Most people agree this is better:
```c++
if (foo()) {
bar();
baz();
}
```
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
|
|
The penalty for breaking before a member access is hard-coded to 150.
Add a configuration option to allow setting it.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
|
|
This renames the `ExportBlockIndentation` option and adds a config parse
test, as requested in #110381.
|
|
indentation of `export { ... }` (#110381)
`export { ... }` blocks can get a bit long, so I thought it would make
sense to have an option that makes it so their contents are not indented
(basically the same argument as for namespaces).
This is based on the `NamespaceIndentation` option, except that there is
no option to control the behaviour of `export` blocks when nested because
nesting them doesn’t really make sense.
Additionally, brace wrapping of short `export { ... }` blocks is now controlled by the
`AllowShortBlocksOnASingleLine` option. There is no separate option just for `export`
blocks because you can just write e.g. `export int x;` instead of `export { int x; }`.
This closes #121723.
|
|
|
|
It wraps the body of namespace with additional newlines, turning this code:
```
namespace N {
int function();
}
```
into the following:
```
namespace N {
int function();
}
```
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
|
|
Closes #120148.
|
|
This fixes #101363 which is a resurrection of a previously opened but
never completed review: https://reviews.llvm.org/D11851
The feature is to allow code like the following not to be broken across
multiple lines:
```
namespace foo { class bar; }
namespace foo { namespace bar { class baz; } }
```
Code like this is commonly used for forward declarations, which are
ideally kept compact. This is also apparently the format that
include-what-you-use will insert for forward declarations.
Also, fix an off-by-one error in `CompactNamespaces` code. For nested
namespaces with 3 or more namespaces, it was incorrectly compacting
lines which were 1 or two spaces over the `ColumnLimit`, leading to
incorrect formatting results.
|
|
Fixes #109864.
|
|
Node uses `.cjs` as an extension for 'common javascript' modules.
|
