ilya-biryukov wrote: Back to the original issue.
> I'm willing to help figure out how to achieve the desired result in a > different way. But for that need to know what is the desired result. We would need to example I shared above to keep working. We rely on an optimization that picks a module with a modular header and imports it rather than a textual one whenever it's available. The reason we cannot change that easily is that: - our module maps are generated by the build system, - our builds are run remotely and we have an optimization that reduces the number of inputs by not shipping the headers if they is an available module that has the header as modular, - our codebase is really big and we have no easy way to find and replace the places we have. Any change on our side is either in compile time or will take long to implement. >From first principles, we need to realign the build optimization for reducing >number of inputs and Clang's module semantics. I would need to confirm that, >but I think that'll boil down to preferring to use a module where header is >modular over another where header is textual, even if the underlying header is >marked as private. Currently we happen to have this behavior by accident >(module with textual header is marked unavailable). We already prefer modules where header is modular over textual, but we the non-private vs private header takes higher priority. I think the change we want is to always prioritize modular over textual, before we look at non-private vs private. The open questions that I have are: - Would that change be breaking? - What are the consequences of picking a different module? (Given that multiple modules for a single header is unusual, it might be that it would not matter, but per Hyrum's law, we want cause problems) If that does not work by default, we would probably need a (`-cc1`? ) flag that we can keep using on our side. https://github.com/llvm/llvm-project/pull/138227 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
