[PATCH] D104222: [clang-format] [PR50702] Lamdba processing does not respect AfterClass and AfterNamespace

christophe-calmejane added a comment. > If you did The only difference (with this current patch) would be the > positioning of the first arguments on `paramBeforeAndAfterLambda` and > `doubleLambda` (I'm not sure the reason for why that is) @MyDeveloperDay The reason is the fix I talked about

[PATCH] D104222: [clang-format] [PR50702] Lamdba processing does not respect AfterClass and AfterNamespace

christophe-calmejane added a comment. In D104222#2821375 , @MyDeveloperDay wrote: >> @MyDeveloperDay >> Of course, sorry for the delay, here it is: >> https://github.com/christophe-calmejane/Hive/blob/master/.clang-format > > You don't have

[PATCH] D104222: [clang-format] [PR50702] Lamdba processing does not respect AfterClass and AfterNamespace

christophe-calmejane added a comment. In D104222#2819403 , @MyDeveloperDay wrote: > @christophe-calmejane are you able to post your .clang-format styles that you > are using, I'm struggling to see where its not matching your style (other > than brace

[PATCH] D104222: [clang-format] [PR50702] Lamdba processing does not respect AfterClass and AfterNamespace

christophe-calmejane added a comment. In D104222#2819324 , @Wawha wrote: > Hi @christophe-calmejane. > I test your code with a old version (few time after the merge of > https://reviews.llvm.org/D44609), and the latest version (commit: > e0c382a9d5a0

[PATCH] D104222: [clang-format] [PR50702] Lamdba processing does not respect AfterClass and AfterNamespace

christophe-calmejane added a comment. Hi, Due to the pandemic, I wasn't able to look at https://reviews.llvm.org/D44609 which got broken since it was pushed to LLVM. Nevertheless I commented in that post with a rather complete unit tests that should pass if any changes are to be pushed to

[PATCH] D44609: [clang-format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)

christophe-calmejane added a comment. In D44609#1875172 , @Wawha wrote: > In D44609#1871612 , @MyDeveloperDay > wrote: > > > Correct follow that description on how to request commit access > > > It's done. I have

[PATCH] D44609: [Clang-Format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)

christophe-calmejane added a comment. I fixed it like this (not sure it's 100% correct though!!) State.Stack.back().HasMultipleNestedBlocks = Current.BlockParameterCount > 1; if (Style.BraceWrapping.BeforeLambdaBody && Current.Next != nullptr && Current.Tok.getKind() ==

[PATCH] D44609: [Clang-Format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)

christophe-calmejane added a comment. Ok I found the issue with noexcept, it's not related to your patch. There is a missing case tok::kw_noexcept: in UnwrappedLineParser::tryToParseLambda Repository: rC Clang https://reviews.llvm.org/D44609

[PATCH] D44609: [Clang-Format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)

christophe-calmejane added a comment. Actually, without your change to HasMultipleNestedBlocks, I'm almost getting the expected result: Lambda body is correctly indented (and not by function name's length). The only thing not working (and it's not either way, with or without your change to

[PATCH] D44609: [Clang-Format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)

christophe-calmejane added a comment. Hi, consider the following code myFunc([](int x) { if (x) call(); }); When activating your BeforeLambdaBody option, it changes the code to this (breaking the start of the lambda to a new line) myFunc( [](int x)