https://github.com/ArcsinX commented:
> I attempted to make scenarios like this more visible with > [d913883](https://github.com/llvm/llvm-project/commit/d91388319892e176740fe0dca896d90309cac780). > There may be more to do here, but in each scenario I could imagine the user > _might_ be doing it intentionally. Thus, I only logged a message for > debugging as opposed to shutting down with an error. I agree that a user might want to do this on purpose. But the problem is that this functionality isn't obvious and would be difficult to describe in a parameter description. This means there are currently several use cases, and the expected behavior of clangd isn't always clear. > Understood. I will point out that a network mount might be more common than > it seems, especially if that enables zero-cost cloning for each developer > workspace. And for the size of some repositories, a local clone isn't > feasible. I acknowledge that repo size might be less common though. I don't know the specifics of your specific scenarios, but based on the initial description, it seems like a web-IDE solution (like code-server) might be more suitable. There may also be issues with users attempting to modify the code simultaneously. And for large projects, the index is usually large, so reading all these files to check index consistency every time clangd starts doesn't seem very efficient. But again, I can't speak with certainty here, as I don't know all the intricacies of your scenarios. > Even if we decide to go with the separate tool, my goal with the latest round > of commits was to get to a place of "this is the best way to do it _if_ we > decide to go this route." Since changes to riff serialization will be needed regardless of development (whether we create a separate tool or it's built into clangd), it might make sense to split this patch. As a first step, only changes to index file serialization/deserialization (plus corresponding tests) https://github.com/llvm/llvm-project/pull/180285 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
