This PR disables llvm-header-guard and llvm-include-order for libc++ and addresses the warnings that are currently activated.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.) | |
libcxx/include/__functional/bind.h | ||
73 ↗ | (On Diff #391151) | |
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 ↗ | (On Diff #391151) | 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" :) |
libcxx/include/regex | ||
2664–2675 | What was clang-tidy complaining about here, specifically? |
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 | ||
70 | This change LGTM. | |
libcxx/include/__functional/bind.h | ||
73 ↗ | (On Diff #391151) | +1 |
libcxx/include/__memory/auto_ptr.h | ||
41–42 ↗ | (On Diff #391151) | 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. |
- 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–2675 | 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? |
libcxx/include/__algorithm/move.h | ||
---|---|---|
68 | Nit: please make sure to strip any trailing whitespace from the changed lines. | |
libcxx/include/regex | ||
2664–2675 | 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 ) |
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. |
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?)