This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by LegalizeAdulthood on Apr 12 2015, 9:59 PM.

Details

Reviewers
alexfh
Summary

Based on feedback from applying this tool to the clang/LLVM codebase, this changeset improves the readability-simplify-boolean-expr check so that conditional assignment or return statements at the end of a chain of if/else if statements are left unchanged unless a configuration option is supplied.

Diff Detail

Event Timeline

LegalizeAdulthood retitled this revision from to Enhance clang-tidy readability-simplify-boolean-expr check to handle chained conditional assignment and chained conditional return.
LegalizeAdulthood updated this object.
LegalizeAdulthood edited the test plan for this revision. (Show Details)
LegalizeAdulthood added a reviewer: alexfh.
LegalizeAdulthood added a subscriber: Unknown Object (MLST).

Add documentation for ChainedConditionalAssignment option.

alexfh edited edge metadata.Apr 13 2015, 3:14 AM

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

clang-tidy/readability/SimplifyBooleanExprCheck.cpp
111

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).

121

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).

211

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.

clang-tidy/readability/SimplifyBooleanExprCheck.h
41

I'd deduplicate some text here:

/// When a conditional boolean return (or assignment) appears at the end
/// of a chain of `if`, `else if` statements, the conditional statement is left
/// unchanged unless the option `ChainedConditionalReturn`
/// (`ChainedConditionalAssignmentis for an assignment) specified as non-zero.
52

Please remove the empty destructor, the top base class has a virtual destructor (we need a check for this as well ;).

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.)

clang-tidy/readability/SimplifyBooleanExprCheck.cpp
111

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.

121

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.

211

I thought about that, but I didn't try it out. I can go either way.

clang-tidy/readability/SimplifyBooleanExprCheck.h
52

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.

clang-tidy/readability/SimplifyBooleanExprCheck.cpp
121

Fixed.

211

I tried this and it gets a compile error because anything() and unless(hasParent(ifStmt())) don't have compatible types.

clang-tidy/readability/SimplifyBooleanExprCheck.h
41

Fixed.

52

Fixed.

LegalizeAdulthood edited edge metadata.

Update based on review comments.

alexfh accepted this revision.May 7 2015, 7:01 AM
alexfh edited edge metadata.

Looks good!

Sorry for the long delay. I was on vacation. Do you need me to commit this for you?

clang-tidy/readability/SimplifyBooleanExprCheck.cpp
208

I guess I missed this in the initial code review.

Using isExpansionInMainFile() you disable fixes in headers which is sub-optimal. I think we should disable fixes in macros (and when a true or false comes from a macro) in a different way: check the relevant source location for being a file location (SourceLocation::isFileID).

This is fine for a follow up.

This revision is now accepted and ready to land.May 7 2015, 7:01 AM
clang-tidy/readability/SimplifyBooleanExprCheck.cpp
208

I will address this in a subsequent refinement.

LegalizeAdulthood edited edge metadata.

Add to CODE_OWNERS.TXT

If this is acceptable, please commit for me, thanks :-).

alexfh added inline comments.May 16 2015, 5:44 PM
CODE_OWNERS.TXT
11

I don't think we add all contributors here. Also, "code author" and "code owner" are different concepts, the latter is defined at the top of this file. I doubt that each clang-tidy check needs a dedicated "owner" as per the definition above.

I'm not going to commit this particular change.

CODE_OWNERS.TXT
11

Either way is fine with me. I was simply attempting to offload support requests from you to me :-).

alexfh closed this revision.May 17 2015, 5:35 AM

Committed revision 237541.