[PATCH] D55433: [clang-tidy] Adding a new modernize use nodiscard checker

MyDeveloperDay via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 8 08:41:44 PST 2019


MyDeveloperDay marked an inline comment as done.
MyDeveloperDay added a comment.



In D55433#1349709 <https://reviews.llvm.org/D55433#1349709>, @JonasToth wrote:

> No problem, thats why we test on real projects first, because there is always something hidden in C++ :)
>
> Is there a test for the lambdas?


test/clang-tidy/modernize-use-nodiscard.cpp line 158  (which is how it manifested inside LLVM) as a lambda assigned to an auto



================
Comment at: clang-tidy/modernize/UseNodiscardCheck.cpp:106
+                    isVariadic(), hasTemplateReturnType(),
+                    hasParent(cxxRecordDecl(isLambda())),
+                    hasClassMutableFields(),
----------------
JonasToth wrote:
> what happens for nested lambdas?
> `hasParent` should be avoided if possible, as the `clangd` folks are currently implementing partial traversal to only analyze "the latest change". If you can, please rewrite that without `hasParent`
I'll not deny I wasn't sure how to do this one, and totally stole the idea from another checker

fuchsia/TrailingReturnCheck.cpp:                                hasParent(cxxRecordDecl(isLambda())))))

> hasParent(cxxRecordDecl(isLambda())),

Given that the matcher is on all CXXMethodDecl, I couldn't quite see how I could determine the CXXMethodDecl was in a lambda, without going to the parent  

{F7804868}

without it I'd get

```
const auto nonConstReferenceType = [] {
   return true;
 };

``` 

transformed to


```
const auto nonConstReferenceType = [[nodiscard]] [] {
  return true;
};

```

Which whilst probably true, made for some ugly reading..

not sure about nested lambdas...sounds even harder!









CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55433/new/

https://reviews.llvm.org/D55433





More information about the cfe-commits mailing list