ChuanqiXu9 wrote: I really hope we can care about user experiences. Currently the complaints about modules in clangd is countless. We should try to make the support usable at first. And also the maintainability is very important too. This is why I choose the minimal workaround.
I hope we can get this merged. Otherwise, maybe I can only make a fork of clangd, work on it and suggesting users to use it. It may be fine for the short term since I am almost the only one who contributes this. But in the long term, this is not good. > Most of your arguments are about limited resources and solution simplicity, > but we should focus on quality > https://llvm.org/docs/DeveloperPolicy.html#quality Here we have performance regression in clangd (but we should not). This is controversial with the following suggestion to disable preamble PCH completely. Again the support of modules in clangd right now is experimental. > I think disabling preamble optimization is still an option (because modules > import is some kind of replacement for precompiled headers), but we should > not build the preamble if we have no plans to use it. But the author also > rejects this option, because it's not so easy to implement and needs more > complex modification. nit picking: it is not preamble but the PCH. What we don't want right now is PCH but not preamble. Conceptually, PCH is a component/optimization of the preamble. Concretely, if we simply skip the preamble, the `canReuse` interface would stop working simply and then users won't get see updated results after one of the included headers get changed. https://github.com/llvm/llvm-project/pull/187432 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
