diff --git a/libcxx/docs/Contributing.rst b/libcxx/docs/Contributing.rst --- a/libcxx/docs/Contributing.rst +++ b/libcxx/docs/Contributing.rst @@ -55,6 +55,42 @@ 4. Create a submodule in ``include/module.modulemap`` for the new header. 5. Update the ``include/CMakeLists.txt`` file to include the new header. +Header layout +============= + +Libc++ uses small and contained headers to implement various features. For example, if +you were going to implement the ``std::ranges::size`` customization point object, you might +consider creating a new header to house this new feature. + +There are a few things to keep in mind when creating new headers: + +* The current naming convention is exactly ``__/.h`` + (note the double underscore mangling of the parent directory only and the ``.h`` file extension on the ``.h`` header). + ``toplevelheadername`` must be the exact name of whatever header the Standard requires + to contain this feature, e.g. ``string`` or ``ranges`` or ``memory``. ``featurename`` + should be the exact public identifier of the feature defined in this header, e.g. + ``iterator_traits`` or ``construct_at``. This should be the only feature defined in this + header. + + - To clarify: the headers should only go one level deep. This means you could create a + header named ``__memory/shared_ptr.h``, but you couldn't create a header + ``__memory/smart_pointers/shared_ptr.h``. + - To clarify: defining exactly one public identifier per header, and naming the header + appropriately forbids headers such as ``__detail/utils.h``. +* All sub-headers should be included by their parent header. To use the example above, + ```` must include the sub-header ``__ranges/size.h``, even if it + doesn't use ``ranges::size`` itself. This inclusion is mandatory because the standard + requires the top level header to provide these declarations. This rule falls out of the + more general "Include What You Use." You should never rely on some other header to + transitively include something that you need. If your header needs a definition of + ``iterator_traits``, then you should either ``#include `` (exactly as user + code does), or, to improve compile time, ``#include <__iterator/iterator_traits.h>``. + You should never expect ``iterator_traits`` to be "pulled in" by any other header. +* User code and test code, on the other hand, should never ``#include`` any of these + helper headers directly; they are intended as unstable implementation details of libc++. +* The synopsis comment for a feature should still go in the parent header. Even if the + feature isn't implemented in the parent header. + Exporting new symbols from the library ======================================