Use header_information to generate the __std_clang_module header. Instead of using lit_header_restrictions like the manually written header did, make a new header_include_requirements to codify what can be included rather than what can be fully tested.
Details
- Reviewers
ldionne Mordante - Group Reviewers
Restricted Project - Commits
- rGf0c5ce0800ea: [libc++][Modules] Generate the __std_clang_module header
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for working on this! I see several not related changes, for now let's keep them but land them separately.
I would like to see a slightly different design before reviewing in-depth.
libcxx/docs/Contributing.rst | ||
---|---|---|
55 | Typically our generated files are stored in git and manually regenerated. This makes it easier to track changes. The 'generated output` CI job regenerated the file and complains when a difference happens. |
libcxx/docs/Contributing.rst | ||
---|---|---|
55 | Are you saying this should move to the libcxx-generate-files target? Or it should be a static file that we have to remember to manually regenerate when we add/remove public headers? |
libcxx/docs/Contributing.rst | ||
---|---|---|
55 | It should be generated by libcxx-generate-files and the output should be committed in the CI. Then when you forget to regenerate the file the CI will warn you. That way the file is available in the release tarball and we are sure it's kept up-to-date. |
libcxx/docs/Contributing.rst | ||
---|---|---|
55 | Alright, I'll get that done, thanks. |
Thanks for working on this! In general happy with the changes, but I like to see the CI green before approving.
libcxx/test/libcxx/assertions/headers_declare_verbose_abort.gen.py | ||
---|---|---|
17 | I would like to see this change and its related changes in a separate review. | |
libcxx/utils/CMakeLists.txt | ||
7 | ||
libcxx/utils/generate_std_clang_module_header.py | ||
2 | Please add a copyright block. | |
29 | Similar warnings are used in other generated headers. | |
48 | The format script complains about the sorting, mainly hunks like -#include <limits> #include <limits.h> +#include <limits> I suspect this is something what happens on Apple where the ordering of . and '>` differs. I know that @ldionne has seen this too. Would it help to force the C locale? This is something we use in other places where we sort data in the CI. | |
49–51 | I feel this is a bit more readable, can you look at using f-strings at other places too. | |
libcxx/utils/libcxx/header_information.py | ||
18–21 | I would like to see these two changes committed separately. When the CI is green feel free to commit these two. |
libcxx/utils/CMakeLists.txt | ||
---|---|---|
7 | But the one above says Generate the <version> header |
libcxx/utils/CMakeLists.txt | ||
---|---|---|
7 | I missed that. Then let's keep it as is. |
libcxx/test/libcxx/assertions/headers_declare_verbose_abort.gen.py | ||
---|---|---|
17 | ||
libcxx/utils/libcxx/header_information.py | ||
18–21 | I put them in https://reviews.llvm.org/D157639, is that ok or should I make one more review? |
libcxx/utils/libcxx/header_information.py | ||
---|---|---|
61 | The module map requires and lit_header_restrictions looked like there were going to be headers that had multiple requirements, which is why the key is requirement tuples. But it turned out that all the headers only have one requirement. Should I keep the tuple keys and support for multiples in the script, or just make the keys strings? |
Thanks for the improvement, this really helps to reduce the maintenance when adding new headers. We don't do it often so more automation is really nice to have.
LGTM!
libcxx/utils/generate_std_clang_module_header.py | ||
---|---|---|
61 | Great comment, thanks! |
libcxx/utils/libcxx/header_information.py | ||
---|---|---|
61 | My preference would be to reinstate something like what we had before https://reviews.llvm.org/D151893. |
libcxx/utils/libcxx/header_information.py | ||
---|---|---|
61 | Sorry for landing so quickly, I'll redo this one and make another PR. |
Typically our generated files are stored in git and manually regenerated. This makes it easier to track changes.
The 'generated output` CI job regenerated the file and complains when a difference happens.