ilya-biryukov added a comment. In D153114#4569591 <https://reviews.llvm.org/D153114#4569591>, @ChuanqiXu wrote:
> BTW, I have a question about supporting header modules (including clang > header modules and C++20 header units) in static analysing tools (including > clangd), "why can't we fallback to include the corresponding headers > simply?". So I still feel it is not a problem to support header modules in > static tools. Since I feel the semantics of header modules is almost > transparent to other tools. We could and it mostly works. In fact, this is what we do internally at Google at build system level since our source tools don't support header modules, but the build does support them. There are problems with this approach, though: - Modules provide build time improvement that add up if they are widely used in the codebase. This leads to source tools being much slower than builds. This results in slowness and timeouts when source tools are used. - There are still incompatibilities between header modules and preprocessor and we occasionally get code that builds, but source tools don't work on it. I think we should be open to special-casing the header modules if they turn out to be hard to support compared to C++20 Modules. However, my intuition is that that would not be the case and the major problems are actually quite similar between the two (versioning of PCMs we consume, when PCMs need to be rebuilt, etc) and we get header modules almost for free if we solve those problem for C++20 Modules. But we do want to make sure we don't miss anything important for header modules in the design phase as that's actually something used by Google today and it would be valuable to solve the aforementioned problems. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D153114/new/ https://reviews.llvm.org/D153114 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
