cxx20 module support for gcc

[loonycyborg]

C++ module support

This PR is aimed is aimed at adding support for C++20 modules for gcc, perhaps also adding infrastructure that could be reused by clang/msvc. Intended interface is to enable module support only if CXXMODULEPATH is set to non-empty path and store module files there.

Contributor Checklist:

• [x] I have created a new test or updated the unit tests to cover the new/changed functionality.
• [ ] I have updated CHANGES.txt (and read the README.rst)
• [ ] I have updated the appropriate documentation

[loonycyborg]

GCC general documentation on modules: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Modules.html Module mapper documentation: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Module-Mapper.html

[mwichmann]

Since there are some other links in the long-running discussion, plus notes on how clang does things, thought I'd mention the Bazel project's issue bazelbuild/bazel#4005

[ZhenyuChen-Boris]

Hey how's this commit going? Any one still following up? If not, I'm kind of interested in this and could be able to pick it up.

[mwichmann]

Any contributions here welcome. We perhaps should have a better place for "discussion" about the right design for this (the one in the PR may in fact be that). In the meantime, this link can be a partial starting point, since it describes a problem and has more links:

https://github.com/urnathan/libcody

There's a newer version of 1184:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1184r2.pdf

Not sure if the mapper/build communication stuff is overkill for a first cut at supporting modules. As I said - maybe a separate location for discussion?

[ZhenyuChen-Boris]

Good to know. But sorry I'm kind of confused by now. Cuz I saw this commit in bazel's issues. But it seems that this is another repo. I'm wondering what's the relationship between these two?

[mwichmann]

relationship? just a problem that all the build systems have to solve, in the face of a not really unified compiler approach to tackling it.

[loonycyborg]

We have a channel for this on Discord. I'll likely prioritize working on this if some other people actually review/try it.

[loonycyborg]

Full blown compiler/buildsystem communication is only used because it's the only way to see actual paths for system headers to support header imports of form import <iostream>;. So mostly I used it because I desire this feature for my own use. However I prefer import std; and thus wouldn't have particular need for system header imports anymore once this is implemented: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852 Maybe could redo this to use plain file lists instead of mapper then.