You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[clang][docs] assert.h is not a good candidate for a textual header (#165057)
The C standard behavior of `assert` cannot be accomplished with clang
modules, either as a normal modular header, or a textual header.
As a normal modular header:
#define NDEBUG
#include <assert.h>
This pattern doesn't work, NDEBUG has to be passed on the command line
to take effect, and then will effect all `assert`s in the includer.
As a textual header:
#define NDEBUG
#include <modular_header_that_has_an_assert.h>
This pattern doesn't work for similar reasons,
modular_header_that_has_an_assert.h captured the value of NDEBUG when
its module built and won't pick it up from the includer. -DNDEBUG can be
passed when building the module, but will similarly effect the entire
module. This has the additional problem that every module will contain a
declaration for `assert`, which can possibly conflict with each other if
they use different values of NDEBUG.
So really <assert.h> just doesn't work properly with clang modules.
Avoid the issue by not mentioning it in the Modules documentation, and
use "X macros" as the example for textual headers.
Don't use [extern_c] in the example modules, that should very rarely be
used. Don't put multiple `header` declarations in a submodule, that has
the confusing effect of "fusing" the headers. e.g. <sys/errno.h> does
not include <errno.h>, but if it's in the same submodule, then an
`#include <sys/errno.h>` will mysteriously also include <errno.h>.
Copy file name to clipboardExpand all lines: clang/docs/Modules.rst
+5-12Lines changed: 5 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -421,13 +421,7 @@ As an example, the module map file for the C standard library might look a bit l
421
421
422
422
.. parsed-literal::
423
423
424
-
module std [system] [extern_c] {
425
-
module assert {
426
-
textual header "assert.h"
427
-
header "bits/assert-decls.h"
428
-
export *
429
-
}
430
-
424
+
module std [system] {
431
425
module complex {
432
426
header "complex.h"
433
427
export *
@@ -440,7 +434,6 @@ As an example, the module map file for the C standard library might look a bit l
440
434
441
435
module errno {
442
436
header "errno.h"
443
-
header "sys/errno.h"
444
437
export *
445
438
}
446
439
@@ -673,14 +666,14 @@ of checking *use-declaration*\s, and must still be a lexically-valid header
673
666
file. In the future, we intend to pre-tokenize such headers and include the
674
667
token sequence within the prebuilt module representation.
675
668
676
-
A header with the ``exclude`` specifier is excluded from the module. It will not be included when the module is built, nor will it be considered to be part of the module, even if an ``umbrella`` header or directory would otherwise make it part of the module.
669
+
A header with the ``exclude`` specifier is excluded from the module. It will not be included when the module is built, nor will it be considered to be part of the module, even if an ``umbrella`` directory would otherwise make it part of the module.
677
670
678
-
**Example:** The C header ``assert.h`` is an excellent candidate for a textual header, because it is meant to be included multiple times (possibly with different ``NDEBUG`` settings). However, declarations within it should typically be split into a separate modular header.
671
+
**Example:** A "X macro" header is an excellent candidate for a textual header, because it is can't be compiled standalone, and by itself does not contain any declarations.
679
672
680
673
.. parsed-literal::
681
674
682
-
module std [system] {
683
-
textual header "assert.h"
675
+
module MyLib [system] {
676
+
textual header "xmacros.h"
684
677
}
685
678
686
679
A given header shall not be referenced by more than one *header-declaration*.
0 commit comments