You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because clang-format cannot determine {} as an empty function is leaves out a space between the ) and the { as it doesn't identify the { as a TT_FunctionLBrace
Add an issue for tracking a potential change to fix that.
While working on a fix for #58217 (namely https://reviews.llvm.org/D135466) we identified that foo(){} was not being identified the same as foo() { return; }
The more I look at this the more I think this is harder than we first think, simply assuming ) { to be a function would change, would then identify the { as a FunctionLBrace, which in turn RemoveSemicolons would remove the trailing ; which is needed i.e.
this
auto i = decltype(x) {};
to this
auto i = decltype(x) {}
which would be a compile error
So we'd really need yet more semantic (or derived semantic) information about what makes {}; a function body.
The unwrappered parser when we are determining the block type is before the annotator which identified the ')' as a TypeDeclarationParen, but this would be useful information to have.
I wonder if there is something we can do after the function name has been identified as FunctionDeclarationName
The more I look at this the more I think this is harder than we first think
I definitely couldn't fix it. I concluded that determining if a function declaration is being dealt with (i.e. Line.MightBeFunctionDecl) happens way later and I couldn't find a non-invasive heuristic that didn't involve lots of duplicated work
Activity
llvmbot commentedon Oct 9, 2022
@llvm/issue-subscribers-bug
llvmbot commentedon Oct 9, 2022
@llvm/issue-subscribers-clang-format
mydeveloperday commentedon Oct 9, 2022
While working on a fix for #58217 (namely https://reviews.llvm.org/D135466) we identified that
foo(){}
was not being identified the same asfoo() { return; }
rymiel commentedon Oct 9, 2022
Also see #57305 (comment). Not exactly a duplicate but the same underlying bug, i'm assuming
mydeveloperday commentedon Oct 9, 2022
The more I look at this the more I think this is harder than we first think, simply assuming
) {
to be a function would change, would then identify the{
as a FunctionLBrace, which in turn RemoveSemicolons would remove the trailing;
which is needed i.e.this
to this
which would be a compile error
So we'd really need yet more semantic (or derived semantic) information about what makes {}; a function body.
The unwrappered parser when we are determining the block type is before the annotator which identified the ')' as a TypeDeclarationParen, but this would be useful information to have.
I wonder if there is something we can do after the function name has been identified as
FunctionDeclarationName
At present we get this..
Expected & Input
Clang-Format current output
rymiel commentedon Oct 9, 2022
I definitely couldn't fix it. I concluded that determining if a function declaration is being dealt with (i.e.
Line.MightBeFunctionDecl
) happens way later and I couldn't find a non-invasive heuristic that didn't involve lots of duplicated workmydeveloperday commentedon Oct 10, 2022
feel free to have a go.
[clang-format] Correctly annotate braces of empty functions
[clang-format] Correctly annotate braces of empty functions (#72733)
5 remaining items