The result from clang commandline is something like
/usr/lib/llvm-7/lib/clang/7.0.1
Which means I need to recompile when the clang is upgraded to newer 7.x.x
However the system has a convenient symlink, which is
/usr/include/clang/7.
/usr/include/c++/9 comes before /usr/include in `{clang,gcc} -v -fsyntax-only -xc++ /dev/null`.
target_include_directories(ccls SYSTEM PRIVATE ${RapidJSON_INCLUDE_DIRS})
If ${RapidJSON_INCLUDE_DIRS} resolves to /usr/include, /usr/include will
be shuffled before /usr/include/c++/9 and will cause `#include_next <stdlib.h>`
issues (see https://github.com/MaskRay/ccls/pull/417).
Check if the include directories are already in CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES.
Note with -fretain-comments-from-system-headers, the .gch of bits/stdc++.h becomes larger by 1%, but that is fine.
And improve comment handling in textDocument/hover
Fix#373
By default, the background indexer doesn't handle names of no linkage.
They are indexed when their files are opened. This saves memory and
makes cache files smaller.
If the workspace folder is a symlink and the client doesn't follow it.
Treat /tmp/symlink/ as canonical and convert every /tmp/real/ path to
/tmp/symlink/.
Combined Daan De Meyer's #227 with other simplification
* USE_SHARED_LLVM is deleted in favor of LLVM_LINK_LLVM_DYLIB
* LLVM_ENABLE_RTTI is deleted as it is provided by LLVMConfig.cmake
* Only direct Clang/LLVM dependencies are required in target_link_libraries
* Restrict -DCLANG_RESOURCE_DIRECTORY= to src/utils.cc
cache.hierarchicalPath: store cache files as $directory/a/b/c.cc.blob to
work around NAME_MAX limitation.
cache.retainInMemory: after this number of loads, keep a copy of file
index in memory. If set to 1, it avoids cache corruption if the index
file is changed after the initial load, which may happen if several
language clients open the same project and share the same cache
directory.
Also rename cacheDirectory cacheFormat to cache.{directory,format}
In clients that support DiagnosticRelatedInformation, display
clang notes as these nested diagnostics rather than appending
them to the parent diagnostic's message. Behaviour for clients
that don't support related information should be unchanged.
