Minimize the testing stdint.h
Thu, Sep 28
Tue, Sep 19
Mon, Sep 18
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.
Thu, Sep 14
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
Wed, Sep 13
Actually allow the stdarg module
Adjust for the changes in D159483.
Tue, Sep 12
__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.
Sat, Sep 9
- 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
Fri, Sep 8
Add the header guard comment to __stddef_null.h
Try deleting the module cache to fix the failing tests
Thu, Sep 7
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
[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
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?
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
Sep 1 2023
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.
Aug 31 2023
Can you add a comment that says the spacing is important please? Although why the heck is musl declaring NULL in stdio.h?
Aug 30 2023
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.
Aug 29 2023
Aug 28 2023
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?
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?
Aug 25 2023
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.
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.
Aug 24 2023
Fixed the failing test
Add a comment why we're including __locale because it's not obvious
Put the clocale include back
Aug 23 2023
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
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!
Also we should figure out why the Clang modules build is failing on top of this, it doesn't look like a false positive.
Aug 22 2023
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
Aug 21 2023
Aug 18 2023
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.
Aug 17 2023
Regenerate the header
Fix the formatting