This is an initial enabling patch for module partition support.
We add enumerations for partition interfaces/implementations.
This means that the module kind enumeration now occupies three
bits, so the AST streamer is adjusted for this. Adding one bit there
seems preferable to trying to overload the meanings of existing
kinds (and we will also want to add a C++20 header unit case later).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
address formatting issues.
not sure why these showed up now and not in previous rebases...
this is the second in an 8 patch series to implement basic C++20 module partition support - here we add module types for partitions (and work on header units will add an additional enumeration in a subsequent series).
clang/include/clang/Basic/Module.h | ||
---|---|---|
109 | I think it's confusing to continue to refer to modules-ts modules at this point. Is that really necessary? | |
517–518 | ??? | |
520 | isModulePartition? |
clang/include/clang/Basic/Module.h | ||
---|---|---|
109 | In this case, I re-used the enumeration since the modules-ts / c++20 modules are disambiguated by the -fmodules-ts flag. So, yes, the enum value does have two uses depending on compilation mode. I can amend the comment to try and make this clear, would that help? I have been trying not to regress anything for modules-ts (and certainly for clang modules) - if someone makes a decision to retire modules-ts then there is probably a bunch of simplification that could be made. With the extra bit to represent the enumeration, we have more space so we *could* have different names for the modules-ts/C++20 interfaces (although I suspect that will just make more code at the use sites, and would prefer not to go down that route). | |
517–518 | thanks, will remove this. | |
520 | works for me, will do. |
clang/include/clang/Basic/Module.h | ||
---|---|---|
109 | IMHO 'modules-ts' is not a useful thing distinct from 'c++20 modules'. The semantics of the TS itself were unclear or broken in places, and only resolved once things got into the std (via 1103/Atom). I think the semantics of '-fmodules-ts' should be the module-specific semantics of C++20 as applied to whatever version of the std being selected (and I'd be fine making it Buyer-Beware for anything before C++20 anyway). But, if you don't want to bite that bullet right now, a clarifying note would be helpful. |
clang/include/clang/Basic/Module.h | ||
---|---|---|
109 | I think we can just go with C++20 and as you suggest treat the TS as a dialect. |
please remind me when this is committed that I'll need to adjust D118352 -- at the moment that's searching for ':' to determine partitionness
I think it's confusing to continue to refer to modules-ts modules at this point. Is that really necessary?
The specific confusion here is that does 'ModuleInterfaceUnit' mean one of two different things depending on compilation mode, or is it a single thing with two different names?