ccls: a fork of the C++ language server cquery

感觉很矛盾，一方面希望自己做的东西能有广泛受众(比如一个学长因此找到了我)，另一方面，项目关注多了issue也多了(没有建设性/用户错误也多了，我真的很想叫这类issue愚蠢)，之前三个月每天看cquery issues很劳累。

现在更多地考虑是自己用着舒服，当然如果能不费太大工夫帮到其他Linux/FreeBSD用户，或是我自己也想尝试知道的一些奇异的配置如cross compiling，我也会愿意做的。有近500个commits加做了大力推广，我确实是居功自傲，但原作者伤人的不仅仅是改变了协作模型，不多提。想到这篇文章会被别人翻译着看挺高兴的呢~LanguageClient-neovim cquery方法、lsp-ui一些东西(主要作者sebastiencs，我早期也做了一点修补)、Wiki、Reddit推广、spacemacs +tools/lsp加已放弃的+tools/cquery(已经转投doom-emacs~)、langserver.org、推动Arch Linux/FreeBSD包、……

Good Friday

如果是今年一月cquery还有很多问题时发生这个变故，我肯定会毫不犹豫fork自立门户再试图超过它。但现在我想不出更加革新性的功能增强，libclang索引的上限我也有所了解，我也没那么多精力在空闲时间再做更多事。前些时候commits多是因为对交叉引用功能不满+拿这个项目学习C++，懂得了一些犄角旮旯的知识。比如clang 3.5推导lambda return type的缺陷，copy initialization用move structor clang 3.9之前的缺陷……玩generic lambda等。

clangd主要开发的人面向超大代码库和Chrome，但他们的方向感觉不对劲，加之code review，一些简单功能也非要用大量代码实现。到现在还在用AST的方法蛮干，没有合适的内存内交叉索引数据结构。现在开始又多了些workspace/symbol等功能，未来重构这些添加的方法只会增加重复劳动。

https://github.com/MaskRay/ccls
https://github.com/MaskRay/emacs-ccls
请求添加到Melpa https://github.com/melpa/melpa/pull/54053

自己做主，主要为自己服务，就能作出很多cquery难以做的选择：

-std=c++17，向telegram-desktop看齐，可以删除variant optional string_view的third-party依赖。用clang++ 6.0.0和系统libstdc++ (gcc 7.3左右)需要这个补丁使得std::get<...>(std::variant<...>)可用。https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/variant?view=markup&pathrev=258854
抛弃textDocument/documentLink textDocument/rangeFormatting $cquery/wait等几乎没用的功能。把.h函数定义放到.cc里这类refactor功能clang-*等外部工具能做的，不值得在language server中实现。这些功能未来会形成命令行/clangd refactor框架，libclang可能永远做不了这些事。
删除默认的-fms-compatibility -fdelayed-template-parsing -fms-extensions。这是原作者revert我的一个commit
删除"command"/"arguments"中对compiler scheduler goma clang的特判。提供给libclang的命令行应该做尽可能少的变换，用户自行添加选项适配自己的项目。
src/下文件实在太多了，很多东西几十行就写成一个新文件。不必要的东西我删除了一些。
修了一个/usr/include/c++/7.3.0/是指向/usr/include/c++/7 symlink时，跳转到系统头文件没有索引信息的问题。
#include ""不补全STL。""中包含系统头文件合法，但是不符合规范。
可以用C++ optional TS filesystem代替各类hack的文件系统函数。
放弃#include <c*>转用C风格#include <*.h>。我比较懒惰，想省std::等几个字。
用stdio，抛弃iostream

import_pipeline file_contents file_consumer等文件，我也比较茫然，每次要改都得重新理论下。这里流程太复杂了，不清楚能怎么简化。

不知道这个项目我能坚持到什么时候，使用请注意风险~

Resurrection Sunday

Building trunk libclang

CXSymbolRole: read/write/addr references
clang_File_tryGetRealPathName: on Arch Linux, system header include paths extracted from clang -E -v -xc++ /dev/null have several ../ path components, which confuse clang_getFileName. You'll need clang_File_tryGetRealPathName to correctly resolve paths of system C++ headers.

They require #if CINDEX_VERSION >= 48, while CINDEX_VERSION shipped with clang 6.0.0 is 45.

Here are instructions to build trunk libclang(see https://llvm.org/docs/CMake.html for LLVM cmake options). Note, please use a powerful workstation to build LLVM.

git clone https://git.llvm.org/git/llvm.git

cd llvm

git clone https://git.llvm.org/git/clang.git tools/clang

cmake -G Ninja -DCMAKE_BUILD_TYPE=MinSizeRel -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DCMAKE_CXX_COMPILER=clang++ \

-DCMAKE_C_COMPILER=clang -DLLVM_OPTIMIZED_TABLEGEN=On -DLLVM_USE_LINKER=lld -Bstatic-release -H.

ninja -C static-release libclang

# Built static-release/lib/libclang.*

If you want to copy built libclang from workstation to local:

rsync -a -f '+ lib' -f '+ lib/clang**' -f '+ lib/libclang.*' -f '- *' \

workstation:~/Dev/llvm/static-release/ ~/Dev/llvm/static-release/

# If you want to use trunk clang as the compiler,

# ninja -C static-release clang

# and add -f '+ bin' -f '+ bin/clang' -f '+ bin/clang++' -f '+ bin/clang-7' on the rsync command line

The libclang headers reside in Dev/llvm/tools/clang while built libraries are in Dev/llvm/static-release. Locate them with CMAKE_PREFIX_PATH.

cmake -G Ninja -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_EXE_LINKER_FLAGS=-fuse-ld=lld \

-DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DSYSTEM_LIBCLANG=On \

-DCMAKE_PREFIX_PATH="$HOME/Dev/llvm/static-release;$HOME/Dev/llvm/tools/clang" -Brelease -H.

cmake --build release

# Built release/ccls whose path can be used to set emacs-ccls variable `ccls-executable`