[clang] [clang][docs] assert.h is not a good candidate for a textual header (PR #165057)

[Richard Smith via cfe-commits]

zygoloid wrote:

> Sure, but if you can't include `<assert.h>` from a modular header, then that basically means `<assert.h>` can't itself be a modular header.

What do you mean by "modular header" here? The terminology I'm familiar with considers textual headers and modular headers to be mutually exclusive -- modular headers are the ones that don't (intend to) depend on the state of translation at the point at which they're entered, and textual headers are the ones that do. I agree (using that definition) that `<assert.h>` can't (or at least, shouldn't) be a modular header.

The purpose of `textual header` declarations is to associate a header with a module so that it is found and its inclusion is permitted by strict `use` checking rules. (There was an idea that we might also store a pretokenized form of textual headers, but that never actually happened.) We want a `use LibC;` to permit including `assert.h`, and don't want it to be a modular import, so it should be listed as a textual header.

> `<modular_header_that_has_an_assert.h>` doesn't usually start its life as a modular header, it just has an inline function with an assert in it, and doesn't expect its behavior to change and start ignoring NDEBUG when it becomes a modular header. In a single module world, fine `<assert.h>` can function the same as textual, but when you add in a second world it starts behaving differently with and without modules.

I'm not following something here -- I think you're suggesting that you'd see some kind of difference when `<assert.h>` is listed as a textual header versus when it's not listed at all (in a simple world without any `use` checking, I assume). What difference do you have in mind?

https://github.com/llvm/llvm-project/pull/165057