MyDeveloperDay added a comment. Part of the problem here is we are not really parsing the Lambda but trying to break based on token annotation only. This can tend to be a bit fragile (normally around corner cases)
The previous approach I think was not constrained enough to just lambdas which is why we had the bleed into other things, also when we added this we didn't really test that it didn't have any impact on anything else. Actually this has been a problem when adding new options. I keep meaning to extend the `LLVMDefaultStyle` `GNUDefaultStyle` `MozillaDefaultStyle` tests to cover all behaviour (if/else/while/do/for/etc..) but also to find a way that when a new option is added we can validate that non of the other aspects of a style aren't broken when using that. (not an easy problem to fix) I'm keen for this NOT to break the AfterClass, AfterNamespace issue, (which is a regression)... we can continue to chip away at corner cases or revert the original change completely. (which I also don't want to do) likely trying to add add parseXXX() functions in UnwrappedLineParser would likely take much longer. I feel like that might offer the better solution but think I would prefer we used that to replace this and gravitate slowly towards a more correct case CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104222/new/ https://reviews.llvm.org/D104222 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
