ChuanqiXu9 wrote: > Please correct me if I'm wrong, but it sounds like the situation we're in is > that Clang has bugs with modules + PCH and those bugs are exposed to clangd > users more readily and cause a bad user experience. So the goal of this patch > is to temporarily disable PCH from clangd when modules are also used, but the > concerns are that users are still paying the cost of PCH generation but not > getting the benefit with their use.
Generally true. But not completely not getting the benefit with the generation of the PCH. For example, in clangd, when we open a file, and some of its (maybe indirectedly) included headers get changed, clangd needs to update the status of the opened file. Currently this is implemented by PrecompiledPreamble, which uses PCH as the underlying components. It is easy to not build the PCH completely. But it is harder to keep these functionality without building PCH completely. > In fact, given that this is an underlying issue in Clang, should Clang be > diagnosing that combination of flags to make it clear that it's currently an > unsupported configuration? Good idea. --- For clangd's users with modules, it should be emphisisized again that the currently modules support in clangd is **experimental** and currently the modules support in clangd doesn't work well. A most recent example is, people who feel clangd working do not using the feature actually: https://github.com/llvm/llvm-project/issues/126350 . In this case, I don't feel it is meaningful to talk about the performance regression here. It is not working. Where does the regression come from? And again, also the maintainability is very important too. This is why I choose the minimal patch, maintainable and understandable. I tried to not building PCH. But I don't like that patch. It is workaround too and not the fundamental fix (fundamental fix lives in the serialization part in clang). Why do we choose a bigger workaround? I think, to move on, I'd like to take the maintainer ship of modules in clangd. I think I can make the right call. I think, in this community, I am the one who cares about C++20 modules users the most. I think we need to care about users in reality instead of in imagination. If I can't make this, or every patch will be so tough to be merged, I think I can only make a fork of clangd and work on it and suggest users to use it. It will much easier for me in the short term. Since I am the almost the only one who contributes to this. But I don't feel that is good for the community in the longer term. https://github.com/llvm/llvm-project/pull/187432 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
