We don't use double underscores for private header names when they are
in a subdirectory with double underscores already.
Details
Details
- Reviewers
• Quuxplusone - Group Reviewers
Restricted Project - Commits
- rGc8b14c03ec74: [libc++][NFC] Fix include guard for decay_copy.h and remove underscores from…
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
I'm happy assuming buildkite is happy!
FWIW, I do see two adjacent open questions, neither of which needs to be addressed in this PR:
- Should <utility> include <__utility/decay_copy.h>? (I have no preference, except for consistency, and even gaining consistency seems like it'll be a bit of an uphill effort)
- Should decay_copy.h really have that // -*- C++ -*- on line 1? @Mordante has pointed out that the comment is useful (to certain syntax-highlighting editors) for files with no extension, such as <string>, but for .h and .cpp files I assume it has little benefit. Right now some __foo/*.h subdirectories are totally comment-less (__compare, __concepts, __random), some are totally comment-ful (__format, __iterator, __memory, __ranges), and some are mixed (__functional, __utility). Personally I prefer comment-less.
Comment Actions
I guess it should, since we statued that <header> should include everything in <__header/*>. We can do that as a separate PR where we fix it for all subdirectories (you're welcome to do that!).
- Should decay_copy.h really have that // -*- C++ -*- on line 1? @Mordante has pointed out that the comment is useful (to certain syntax-highlighting editors) for files with no extension, such as <string>, but for .h and .cpp files I assume it has little benefit. Right now some __foo/*.h subdirectories are totally comment-less (__compare, __concepts, __random), some are totally comment-ful (__format, __iterator, __memory, __ranges), and some are mixed (__functional, __utility). Personally I prefer comment-less.
I dislike those comments too, however they have started proving useful for the extension-less since I'm using VS Code (for some reason, it doesn't guess the language otherwise). I think we should be consistent and use it everywhere.