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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
