[clang-format] Add ObjCSpaceBeforeMethodDeclColon option to control
space before Objective-C method return type
This patch introduces the ObjCSpaceBeforeMethodDeclColon style option,
allowing users to add or remove a space between the '-'/'+' and the
return type in Objective-C method declarations (e.g., '- (void)method'
vs '-(void)method').
Includes documentation and unit tests.
This fixes the `SpaceBeforeParensOptions.AfterFunctionDeclarationName`
and `SpaceBeforeParensOptions.AfterFunctionDefinitionName` options not
adding spaces when a template type's constructor or destructor is
forward declared or defined outside of the type definition.
Attribution Note - I have been authorized to contribute this change on
behalf of my company: ArenaNet LLC
Currently, in the following snippet, the second designated initializer
is incorrectly detected as an OBJC method expr. Fix that and a test to
make sure we don't regress.
```
Foo foo[] = {[0] = 1, [1] = 2};
```
Replace the `AlwaysBreak` and `BlockIndent` suboptions of
`AlignAfterOpenBracket` with new style options `BreakAfterOpenBracket*`
and `BreakBeforeCloseBracket*` for `*` in `BracedList` for braced list
initializers, `if` for if conditional statements, `Loop` for loop
control statements (for/while), `Switch` for switch statements, and
`Function` for function calls/declarations/definitions.
Deprecates `AlwaysBreak` and `BlockIndent`.
Fixes#67738Fixes#79176Fixes#80123Fixes#151844
For declarations like `Type* ::Class::member...`, `Class` was not
annotated as `TT_StartOfName`as it should be. This prevented `member`
from being updated to `TT_FunctionDeclarationName` if `member` was a
function name.
Fixes#164866
after, with style `{ColumnLimit: 60}`
```Objective-C
[objectName
respondsToSelector:
@selector(
somelonglonglonglongnameeeeeeee:
loooooooooanotherlonglonglonglongnametopush:
otherlongnameforlimit:)];
```
before
```Objective-C
[objectName
respondsToSelector:
@selector(
somelonglonglonglongnameeeeeeee:loooooooooanotherlonglonglonglongnametopush:otherlongnameforlimit:)];
```
Fixes#164574.
The stuff inside the parentheses got a new type in 2a059042882ed. I
neglected to add it to the logic for breaking lines.
Reverts llvm/llvm-project#164048
This led to a regression in clang-format where a space gets added in
between the parameter type and `&`. For example, this
```
::test_anonymous::FunctionApplication& ::test_anonymous::FunctionApplication::operator=(const ::test_anonymous::FunctionApplication& other) noexcept {
```
becomes
```
::test_anonymous::FunctionApplication& ::test_anonymous::FunctionApplication::operator=(const ::test_anonymous::FunctionApplication & other) noexcept {
```
Fixes http://llvm.org/PR55487 (#55487)
The code did not match the documentation about Cpp11BracedListStyle.
Changed handling of comments after opening braces, which are supposedly
function call like to behave exactly like their parenthesis counter
part.
Fixes#36459.
after
```Objective-C
- (void)test {
if ([object
respondsToSelector:@selector(
selectorNameThatIsReallyLong:param1:param2:)])
return;
}
```
before
```Objective-C
- (void)test {
if ([object respondsToSelector:@selector
(selectorNameThatIsReallyLong:param1:param2:)])
return;
}
```
Before this patch, the `ObjCMethodExpr` type was assigned to many kinds
of tokens. The rule for allowing breaking the line before the colon on
line TokenAnnotator.cpp:6289 was intended for method declarations and
calls. It matched the parenthesis following `@selector` by mistake. To
fix the problem, this patch adds a new type for `@selector`. Most of the
special things in the code related to the old type is intended for other
constructs. So most of the code related to the old type is not changed
in this patch.
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.
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.
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.
