ccls seems to get confused when trying to find libc++ when libc++ itself is being built

[lanza]

I work on lldb and other llvm projects and my regular build includes libcxx. Thus libcxx ends up as just part of the built products of the compile_commands.json.

When I open some arbitrary llvm file that uses #include <memory>, for example, it complains that it can't find the file and then can't find the usages of std::unique_ptr. However, go-to definition on std::unique_ptr takes you to "src/llvm-project/libcxx/include/memory".

My setup is src/llvm-project/build/Debug/ as the build directory and then ln -s /path/to/src/llvm-project/build/Debug/compile_commands.json /path/to/src/llvm-project/llvm/. Then I CD to llvm-project/llvm and open neovim and open, e.g. include/llvm/DebugInfo/PDB/PDBSymbol.h and it can't find std::unique_ptr though go-to-def takes you to llvm-project/libcxx/include/memory.

If I switch to standalone builds and relink the compile_commands.json to the standalone one everything works fine.

[MaskRay]

However, go-to definition on std::unique_ptr takes you to "src/llvm-project/libcxx/include/memory".

If I switch to standalone builds and relink the compile_commands.json to the standalone one everything works fine.

I'm confused. Are you using separate git repositories or mono git repo or mono svn repo?

I can think of two problems for what you described:

1. You use symlinks. See If the workspace folder is a symlink, convert paths relative to it #314

2. You have multiple repositories and the root project detection isn't correct for you. My configuration:

git clone https://git.llvm.org/git/llvm.git
git clone https://git.llvm.org/git/clang.git llvm/tools/clang
git clone https://git.llvm.org/git/lldb.git llvm/tools/lldb  # lldb must be beside clang
git clone https://git.llvm.org/git/lld.git llvm/projects/lld  # lld doesn't have to
git clone https://git.llvm.org/git/compiler-rt.git llvm/projects/compiler-rt
# other git clone commands omitted
touch .ccls-root
# cmake -H. -BDebug <other options>
ln -s Debug/compile_commands.json

I use lsp-mode + emacs-ccls. .ccls-root as the root indicator overrides .git. Many language clients use .git as the root indicator and think llvm/tools/clang llvm/tools/lldb are themselves the project roots though they aren't (they are part of llvm). They may spawn several ccls processes and some of them do not have compile_commands.json. See https://github.com/MaskRay/ccls/wiki/FAQ#project-root-detection for more information.

[lanza]

I work on Swift and thus my layout is all separate git repo checkouts

swift-project/
    .ccls-root
    swift
    llvm
    clang
    lldb
    libcxx
    build/Debug
    compile_commands.json  -> build/Debug/compile_commands.json

I don't use their build system, though. I use

cmake ...flags... \
    -DLLVM_ENABLE_PROJECTS="clang;lldb;swift;libcxx;..others" \
    -DLLVM_EXTERNAL_PROJECTS="swift"` \
    -B swift-project/build/Debug \
    -S swift-project/llvm

I touch swift-project/.ccls-root and set my CocConfig to use .ccls-root as the root marker.

You use symlinks. See #314

Nope.

Ultimately, /Applications/Xcode..../include/c++/v1/memory never gets cached while swift-project/libcxx/include/memory and swift-project/build/Debug/include/c++/v1/memory do. Neither of these paths are included as part of the entry in the compile_commands.json database. So many ccls is thinking "I already have that file" and thus not caching it but then later can't find it because it wasn't cached?

[MaskRay]

OK, I conclude that this is not a server-side issue.

I touch swift-project/.ccls-root and set my CocConfig to use .ccls-root as the root marker.

I assume cross references among swift-project/{llvm,swift,clang,lldb} are correct now.

-DLLVM_ENABLE_LIBCXX just appends -stdlib=libc++. If you want to bootstrap llvm with the in-tree libc++, you need a two-stage build, otherwise it is expected that for most files textDocument/definition on #include <memory> jumps to /Applications/Xcode..../include/c++/v1/memory.

Ultimately, /Applications/Xcode..../include/c++/v1/memory never gets cached while swift-project/libcxx/include/memory and swift-project/build/Debug/include/c++/v1/memory do.

When you jump to a file outside of the project, your language client doesn't know that the file is in the same project. It may think /Applications/Xcode..../include/c++/v1/ or /Applications/Xcode..../include/c++/ or another directory is the new project and spawn a new ccls process there.

An analogy on Linux is that after you textDocument/definition on #include <stdio.h> takes you to /usr/include/stdio.h, you want stdio.h to be associated with the original workspace.

[MaskRay]

May I ask the memory usage of ccls indexing swift-project? And does it get lots of improvement after #345 ?