[PATCH] Enhance clang-tidy readability-simplify-boolean-expr check to handle chained conditional assignment and chained conditional return

Richard legalize at xmission.com
Mon Apr 13 11:18:35 PDT 2015


In http://reviews.llvm.org/D8996#155356, @alexfh wrote:

> Do we actually need two separate options here? Which combination of these would you use for LLVM code?


Since this is a readability check and "beauty is in the eye of the beholder", I didn't want to make decisions for the user.  This extension of the check embraces LLVM preferences by default based on feedback from the use of the check on the clang/LLVM code.  (In particular, these two issues came up in the review of changes to clang/lib/Parse and clang/lib/AST.)


================
Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:111
@@ -110,4 +110,3 @@
         return (getText(Result, *BinOp->getLHS()) + " " + NegatedOperator +
-                " " + getText(Result, *BinOp->getRHS()))
-            .str();
+                " " + getText(Result, *BinOp->getRHS())).str();
       }
----------------
alexfh wrote:
> The text on the left is clang-formatted. I prefer to keep code clang-format-clean, so if you don't like the result, please file a bug against clang-format rather than changing the formatting by hand (I personally don't care in this case).
This change was introduced by clang-format from the latest.  I don't apply any of my own personal taste in formatting anymore, but routinely run everything through clang-format before posting for review.

================
Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:121
@@ +120,3 @@
+
+bool get(const OptionsView &Options, StringRef LocalName) {
+  return Options.get(LocalName, 0U) != 0U;
----------------
alexfh wrote:
> I don't think this function makes code shorter or easier to understand. I'd remove it and use the implementation directly (maybe with implicit conversion to bool to avoid the ` == 0U` part).
I meant to bring this up on the mailing list.  I got stuck for a while because `bool b = false; Options.get(LocalName, b);` totally failed when `LocalName` was configured to `true`.  I tried to dig into it and figure out why, apparently there is a member function template that is `enable_if`'ed for integral types and because `bool` is an integral type, it was trying to turn `true` into an integer and silently failing, leaving my boolean setting unset.  I'd rather have the setting just plain work for booleans because it's weird to turn this yes/no option into 1/0 in the configuration.  So I was trying to have a local function that did "what I wanted" from OptionView until I could figure out how to get OptionView to properly handle boolean options.

================
Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:211
@@ -201,5 +210,3 @@
                                                   bool Value, StringRef Id) {
-  Finder->addMatcher(ifStmt(isExpansionInMainFile(),
-                            hasThen(ReturnsBool(Value, ThenLiteralId)),
-                            hasElse(ReturnsBool(!Value))).bind(Id),
-                     this);
+  if (ChainedConditionalReturn) {
+    Finder->addMatcher(ifStmt(isExpansionInMainFile(),
----------------
alexfh wrote:
> How about:
> 
>       Finder->addMatcher(ifStmt(isExpansionInMainFile(),
>                               ChainedConditionalReturn ? anything() : unless(hasParent(ifStmt())),
>                               hasThen(ReturnsBool(Value, ThenLiteralId)),
>                               hasElse(ReturnsBool(!Value))).bind(Id),
>                        this);
> 
> ? (if this works, of course)
> 
> Same below.
I thought about that, but I didn't try it out.  I can go either way.

================
Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.h:52
@@ +51,3 @@
+  SimplifyBooleanExprCheck(StringRef Name, ClangTidyContext *Context);
+  virtual ~SimplifyBooleanExprCheck() {}
+
----------------
alexfh wrote:
> Please remove the empty destructor, the top base class has a virtual destructor (we need a check for this as well ;).
OK.  Most code bases where I've worked had explicit preferences for virtual d'tors to remind readers that the class participates in a virtual method hierarchy.

http://reviews.llvm.org/D8996

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the cfe-commits mailing list