https://github.com/ArcsinX commented:
>From clangd standpoint I support resolving relative paths (as described in the >PR title), but I have concerns about resolving symlinks. TLDR; Holding real paths the compilation database doesn't mean that via LSP we will receive real paths. I mean that we still can receive symlinked paths via LSP and there can be problems with compile command lookup. Also, I remember there were problems with background indexing start in case of symlinked root directory (but opening project via real path), here we can face this problem from another standpoint (we are using symlikned paths everywhere and background indexing won't start because somewhere we resolve symlinks). I didn't check that this patch really introduced the problem which I mentioned above (can do this if really needed, but this can take some time), but I expect these problems and maybe some other because symlinks-related problems reports happen from time to time in clangd, and it seems to address all symlinks-related problems in clangd we need to resolve all paths (including paths inside compile command, like -I<path-is-here>). So, I think for now the better approach is to keep symlinks unresolved everywhere (or resolve everywhere, but this maybe won't be easy to implement keeping in mind that this will lead to performance degradation, especially on slow filesystems like NFS) https://github.com/llvm/llvm-project/pull/235400 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
