This is an archive of the discontinued LLVM Phabricator instance.

[libc++][NFC] Address clang-tidy warnings in include/
AbandonedPublic

Authored by philnik on Dec 1 2021, 3:26 PM.

Details

Reviewers
ldionne
Quuxplusone
Mordante
Group Reviewers
Restricted Project
Summary

This PR disables llvm-header-guard and llvm-include-order for libc++ and addresses the warnings that are currently activated.

Diff Detail

Event Timeline

philnik created this revision.Dec 1 2021, 3:26 PM
philnik requested review of this revision.Dec 1 2021, 3:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 1 2021, 3:26 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Quuxplusone added inline comments.
libcxx/include/__algorithm/copy.h
72

FWIW, I find the left-hand code easier to read and easier to safely-modify than the right-hand code. (This applies, for me, everywhere clang-tidy is introducing early-returns and/or removing braces from if-bodies.)
However, if we really want to do this, I won't loudly object.

libcxx/include/__functional/bind.h
73

These comment-only diffs are clearly a good idea and you should just land them immediately in their own commit, in order to shorten this PR. (Maybe wait for @ldionne or @Mordante or @cjdb to +1 this comment, for the sake of protocol.)

libcxx/include/__functional/hash.h
225–230

The original binary-tree-of-ifs was clearly done intentionally, and this is tight-loop code; but if I had to bet one way or the other, I guess I'd bet this refactor was fine. If done, it should be landed in its own commit, for ease of bisecting.

libcxx/include/__memory/auto_ptr.h
41–42

This specific suppression seems OK, but then you do this like a million more times, for other assignment operators, for various reasons such as "oh no it uses enable_if" :)
I think you should just add -misc-unconventional-assign-operator to the .clang-tidy file. That instantly removes like half of the diffs in this PR.

libcxx/include/regex
2664–2672

What was clang-tidy complaining about here, specifically?
Don't these diffs change a tail-call into a non-tail-call, and isn't that generally a bad thing? (Of course in these cases the optimizer will DTRT anyway, but I bet it's a pessimization for -O0 mode.)

ldionne requested changes to this revision.Dec 2 2021, 5:22 AM

In general, I like the comment fixes and some of the reformatting, however I don't see the point of most of the control flow changes, and in many cases it felt to me like the status quo was better.

libcxx/include/__algorithm/minmax_element.h
50

Honestly, I find the left hand side easier to read -- I don't understand why clang-tidy is suggesting this change. Anyone?

libcxx/include/__bit_reference
69

This change LGTM.

libcxx/include/__functional/bind.h
73

+1

libcxx/include/__memory/auto_ptr.h
41–42

Agreed -- IMO clang-tidy and such tools are well suited for normal code bases, however this is the Standard Library, and sometimes we have to do things that are outside of what should be considered "normal". For instance, we *have* to leave these unconventional assignments there because they are required by the Standard -- in a normal code base I'd even go further and remove everything that mentions auto_ptr, but obviously that doesn't apply to us.

This revision now requires changes to proceed.Dec 2 2021, 5:22 AM
philnik updated this revision to Diff 391295.Dec 2 2021, 5:53 AM
philnik marked 5 inline comments as done.
  • factored out namespace comments into D114947
  • disabled misc-unconventional-assign-operator
  • refactored minmax_element
libcxx/include/__algorithm/minmax_element.h
50

I think it is 'move the code to the left as much as possible'. I definitely agree with the sentiment, and personally don't really find it harder to read. Do you want to keep else in general or only in this specific case?

libcxx/include/regex
2664–2672

clang-tidy complains that operator=() does not return *this (it's another case of misc-unconventional-assign-operator). It does of course return *this through assign, but I think explicitly returning *this makes it look less weird. I thought it would compile to the same assembly, but that probably isn't the case in -O0. I'll revert the changes when I disable misc-unconventional-assign-operator. And what does DTRT stand for?

Quuxplusone added inline comments.Dec 2 2021, 8:40 AM
libcxx/include/__algorithm/move.h
68–72

Nit: please make sure to strip any trailing whitespace from the changed lines.

libcxx/include/regex
2664–2672

DTRT = Do The Right Thing (with a somewhat ironic connotation that the "right thing" is "obvious" and therefore can be handwaved).

(For the record, experimental evidence agrees that the right-hand side's assembly is the same at -O1 and slightly worse at -O0: https://godbolt.org/z/x7rjTjz4a )

Quuxplusone added inline comments.Dec 2 2021, 8:42 AM
libcxx/.clang-tidy
2

I don't know if we're close to consensus one way or the other on the if-else/early-return refactorings, but IMHO this one-line diff in the .clang-tidy file is now uncontroversial and can be landed ASAP if you want. (Someone +1 that?)

I'm happy with the few places that only re-format existing code in obvious ways, but anything where we change else if into if or things like that, I don't think it improves the code. I also think removing { and } from single-statement ifs is not really a plus in most cases that I've seen in this patch.

libcxx/.clang-tidy
2

Yeah, +1 on adding this part. All the rest of the patch, I don't think much of it is an improvement over what we had before.

philnik abandoned this revision.Dec 2 2021, 12:12 PM