This is an archive of the discontinued LLVM Phabricator instance.

[libc++][clang-tidy] Enable readability-simplify-boolean-expr
ClosedPublic

Authored by philnik on Nov 10 2022, 2:58 PM.

Diff Detail

Event Timeline

philnik created this revision.Nov 10 2022, 2:58 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: xazax.hun. · View Herald Transcript
philnik requested review of this revision.Nov 10 2022, 2:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 10 2022, 2:58 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Eugene.Zelenko added inline comments.
libcxx/.clang-tidy
31

Please keep alphabet order.

philnik updated this revision to Diff 476740.Nov 20 2022, 3:53 AM
philnik marked an inline comment as done.
  • Rebased
  • Address coment
Eugene.Zelenko retitled this revision from [libc++][clang-tidy] Enable readability-siplify-boolean-expr to [libc++][clang-tidy] Enable readability-simplify-boolean-expr.Nov 20 2022, 7:36 AM
ldionne requested changes to this revision.Nov 20 2022, 11:36 AM

I am not against this, but it's not clear to me that this really increases readability that much, since 50% of the changes suggested by the tool are not improvements IMO.

libcxx/include/charconv
253

I don't find the new one to be more readable. The old one read more naturally as "if *__p is not between '0' and '9'". The new one isn't as clear.

libcxx/include/fstream
755–756

Here too, I don't find the new formulation more readable.

libcxx/include/locale
4015–4016

Same.

This revision now requires changes to proceed.Nov 20 2022, 11:36 AM

I am not against this, but it's not clear to me that this really increases readability that much, since 50% of the changes suggested by the tool are not improvements IMO.

I'm actually quite surprised by that, given that I find the second one you commented on basically unreadable in the current state. Maybe I'm just exceptionally bad at reading negations though.

libcxx/include/charconv
253

Here I don't care super much, but I'd read the new version as "if *__p is outside 0 to 9". IMO "outside" is a bit nicer than "not inside", which I'd mentally convert to "outside".

libcxx/include/fstream
755–756

In this case I find the new version much more readable. Instead of "it's not the case that __extbufnext_ is null and __extbufend_ is not equal to __extbufnext_", it reads to me as "__extbufnext_ is not null or __extbufend_ is equal to __extbufnext_". In case of the second one I instantly know that the the iterator is non-null or range is empty; IOW check that we don't dereference a nullptr. To get to that conclusion I actually have to DeMorgan the original version in my head.

ldionne added inline comments.Nov 22 2022, 8:31 AM
libcxx/include/charconv
253

What I like about the previous formulation is that '0' <= *__p && *__p <= '9' immediately reads as 0 <= p <= 9 in my head, I have no need to even think about it. I can't say the same for '0' > *__p || *__p > '9'.

In general though -- if we enable this clang-tidy check, what do we do when the tool suggests something that we don't agree with? Can we turn it off for this warning? Tools are nice but I want us to keep in mind that they're only tools meant to help us, the humans, do a better job. If a tool suggests something we don't think is better, we should be happy to turn it off for that instance.

libcxx/include/fstream
755–756

When I read an assertion, I generally read it as assert(!bad-condition-that-shouldnt-happen). In this case, the left hand side made that really clear. With your explanation I do agree that the right hand side also makes sense, but I would then change the code to this instead:

if (__extbufend_ != __extbufnext_) {
    _LIBCPP_ASSERT(__extbufnext_ != NULL, "underflow would be calling memmove on a nullptr");
    _VSTD::memmove(__extbuf_, __extbufnext_, __extbufend_ - __extbufnext_);
}

This makes it clearer that we're specifically trying to guard against this nullptr condition in memmove. WDYT?

I too am not convinced by this clang-tidy check. I agree it makes the expression simpler, but it seems to make certain cases harder to understand since the "complex" form is more intuitive. I am happy to see we only have a few places where clang-tidy wants to improve our code!

libcxx/include/charconv
253

+1 I find this quite confusing. I would write the original or if (*__p < '0' || *__p > '9').

philnik updated this revision to Diff 477262.Nov 22 2022, 11:29 AM
philnik marked 3 inline comments as done.

Address comments

libcxx/include/charconv
253

IMO @Mordante's version is the most readable. @ldionne any objections to that?

Re. disabling a check: You can use // NOLINT, // NOLINTNEXTLINE and // NOLINTBEGIN + // NOLINTEND to ignore clang-tidy. Optionally, you can also use //NOLINT*(clang-tidy-check-to-ignore) to disable a specific check (IMO this should be the default). For more details see https://clang.llvm.org/extra/clang-tidy/index.html#suppressing-undesired-diagnostics.

libcxx/include/fstream
755–756

Sounds good.

ldionne accepted this revision.Nov 22 2022, 2:22 PM
ldionne added inline comments.
libcxx/include/charconv
253

@Mordante 's suggestion is fine with me.

This revision is now accepted and ready to land.Nov 22 2022, 2:22 PM

For what it's worth, the clang tidy check can be configured to disable transformations based off DeMorgan's law.

This revision was landed with ongoing or failed builds.Nov 23 2022, 3:42 PM
This revision was automatically updated to reflect the committed changes.