Minimize the testing stdint.h

In D159064#4647709, @vsapsai wrote:

Still going through the patch and through the discussion. But wanted to ask if there are any complications in reverting this change? For libc++ we've discussed that we don't really know the perf impact of multiple small modules. So I want to make sure we aren't making decisions that make it impossible to revert the change later.

Update clang/test/Modules/stddef.c: it doesn't need a different verify label for -fbuiltin-headers-in-system-modules, allow the diagnostic to suggest either definer of size_t, add another test to make sure that size_t still works when both declarations are seen

Actually allow the stdarg module

Adjust for the changes in D159483.

__stddef_max_align_t.h always needs a header guard, because the type merger can't handle struct's. If it has a header guard then it always needs to have a module too, even if -fbuiltin-headers-in-system-modules is passed.

I was talking to Ben about this one a little today since I ended up needing to make the same -isystem/-I -> -internal-isystem switch in some of the unit tests in D159064, and also add a clang/test/Modules/Inputs/System/usr/include/inttypes.h.

• Drop the -verify off the stddef tests so that I can get the full errors

• Drop the -verify off the new tests so that I can get the full errors

Add the header guard comment to __stddef_null.h

Try deleting the module cache to fix the failing tests

Rebase

Rebase

Rebase

Add comments to stdarg.h and stddef.h explaining their interesting header guard setup.
Ignore -fbuiltin-headers-in-system-modules if -fmodules isn't passed.
DriverKit doesn't need to pass -fbuiltin-headers-in-system-modules since it doesn't have a module map at all.
Add a test for -fbuiltin-headers-in-system-modules/__has_feature(builtin_headers_in_system_modules)
Miscellaneous review feedback

In D155141#4631516, @ldionne wrote:

[Github PR transition cleanup]

I've said it before but I think this is too complicated and we don't have a clear picture of the benefits. I would prefer abandoning this patch, but if you really want to move forward with it, please provide compelling evidence of why this complexity is worth adding.

This was succeeded by D158709.

Fix formatting issue

Rebase

Fix formatting

In D159483#4641289, @benlangmuir wrote:

How does this work today? Wouldn't the include guard prevent this?

Today they don't define their include guard when building with modules.

Thanks - I can see some headers behave that way, or in other cases there are other sorts of has_feature(modules) checks that I can see you're modifying, but what about all the *va_* headers that currently just seem to have normal header guards?

In D159483#4641231, @benlangmuir wrote:

but need to be repeatedly included when they're used in system modules

How does this work today? Wouldn't the include guard prevent this?

A big assumption this patch makes is that ModuleMap::isBuiltinHeader is primarily to support Apple's unfortunate module needs. Thus this patch turns that behavior off by default, which makes things work the way one would expect. That is, when usr/include/module.modulemap references stdint.h, that just means usr/include/stdint.h and it doesn't also pull in the clang builtin stdint.h, it doesn't transform usr/include/stdint.h into a textual header, etc. I'm hoping that's acceptable behavior on non-Apple platforms, but if someone knows otherwise please let me know and we can rethink how the option should be defined and set.

Rebase on top of D159483

Ah, the tests are failing because some of them are putting the builtin headers in other modules. This is going to need the "optionally ignore the builtin modules" change first then. I almost have that one finished.

Can you add a comment that says the spacing is important please? Although why the heck is musl declaring NULL in stdio.h?

Update Module::directlyUses

The nullptr_t submodule can't require c23 because it needs to be used in C++ in some cases too. Remove the requires from the module map and add a C23 guard to the header.

Add @import tests for all of the new modules

Remove the module cache before running the stdarg/stddef unit tests in module mode

remove the extra #endif (which oddly didn't produce an error locally so I must've ran the tests wrong the first time...)

Would we want to back port this to llvm 17?

In D158709#4621199, @aaron.ballman wrote:

At a high-level (not just for this patch, but for the entire series): is this need specific to your downstream or is this a more general need? e.g., should this complexity be kept downstream until we've got a second platform needing it?

Modules don't support the #include #undef #include pattern to redefine macros, the second include has no effect. Move the #undef of NULL into __stddef_null.h so that the textual behavior is preserved, but the module behavior doesn't leave NULL undefined.

In D158709#4617295, @aaron.ballman wrote:

I'm a bit concerned about the impact on (non-modules) build time performance. This splits stddef.h and stdarg.h into needing to open 14 different files instead of 2. Hopefully that's not a lot of overhead, but given that stddef.h is included in approximately every TU and that sometimes external forces cause files to be slow to open (network drives, AV software, etc), I think we should be cautious and measure the impact. I also really do not like how poorly this scales -- the fact that this is only needed for these two files helps a bit, but this is a lot of C++-specific hoops to jump through for C standard library headers.

Rebase

Fixed the failing test

Add a comment why we're including __locale because it's not obvious

Put the clocale include back

Windows succeeding earlier, I'm pretty confident that the current crash isn't due to this review, so I'm going to go ahead and land.

Try rebasing one more time

Rebase

In D157757#4611492, @iana wrote:

In D157757#4611425, @ldionne wrote:

Also we should figure out why the Clang modules build is failing on top of this, it doesn't look like a false positive.

Where do you see that failure?

It looks like we don't have unit tests/CI for undef(_LIBCPP_HAS_NO_LOCALIZATION) + undef(_LIBCPP_LOCALE__L_EXTENSIONS). If anyone knows how to set that up please let me know!

In D157757#4611425, @ldionne wrote:

Also we should figure out why the Clang modules build is failing on top of this, it doesn't look like a false positive.

Only define nullptr_t in C++ if _MSC_EXTENSIONS is defined, even if __need_nullptr_t is explicitly set.

Update nasty_macros.gen.py's path to header_information

In D157757#4600357, @ldionne wrote:

This is going to be really naive, but can someone explain why we need these __need_XXXXX macros? Why doesn't <stddef.h> simply always declare what it should declare? Also, does anybody understand the expected relationship between the C Standard Library headers and these Clang builtin headers? Who defines what?

Everyone I've spoken to so far about this (and myself) was extremely confused. At some point I thought these macros were only needed for compatibility with old glibcs but that wouldn't even be needed anymore, but I'm not certain.

Regenerate the header

Fix the formatting