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.
Details
Diff Detail
Event Timeline
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 ;). |
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. |
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 | ||
---|---|---|
212 | 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. |
clang-tidy/readability/SimplifyBooleanExprCheck.cpp | ||
---|---|---|
212 | I will address this in a subsequent refinement. |
CODE_OWNERS.TXT | ||
---|---|---|
11 ↗ | (On Diff #25922) | 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 ↗ | (On Diff #25922) | Either way is fine with me. I was simply attempting to offload support requests from you to me :-). |
I'd deduplicate some text here: