fork了cquery => ccls emacs-ccls

闲聊灌水
1

感覺很矛盾，一方面希望自己做的東西能有廣泛受衆(比如一個學長因此找到了我)，另一方面，項目關注多了issue也多了(沒有建設性/用戶錯誤我真的很想叫這類issue 愚蠢的issue也多了)，之前三個月每天看cquery issues很勞累。原作者一開始發標題爲"Comments in 2efe70ecc…"的空內容issue，表達不滿(但他自己不能積極點修問題麼)，有時也在gitter裏表達不滿，關掉issue他有時會reopen(前幾天我看到他可能稍微糾正了這個習慣)。終於在最近實際性revert我三個commits加刪掉了我們其他人的push access。

現在更多地考錄是自己用着舒服，當然如果能較容易幫到其他Linux/FreeBSD/(我自己也想嘗試知道一些奇異的配置如cross compiling)用戶的情況下也會願意做。有近500個commits加做了大力推廣(LanguageClient-neovim cquery方法、lsp-ui很多東西、wiki、reddit、spacemacs(這個已放棄，轉投doom-emacs~) langserver.org …)，有時發發牢騷：“bad DFL”，或者說“同學來了，雖然我不開心但是再發一個PR吧”，Twitter上非常正常的status他都能曲解成惡意攻擊他，變相威脅我。

Good Friday

如果是一月還有很多問題，我肯定會毫不猶豫fork再試圖超過它。現在我很清楚libclang工具的上限，沒有什麼可改進的了，我也沒那麼多精力再做更多事。 前幾個月commit這麼多是因爲拿這個項目學習C++和一些犄角旮旯的知識。比如clang 3.5推導lambda return type的缺陷，copy initialization用move structor clang 3.9之前的缺陷……玩generic lambda等

clangd主要開發的人想的是超大代碼庫和Chrome，但感覺他們思路有問題，而且code review效率很低，一些簡單的功能也非要用大量代碼實現。現在沒有妥善index的情況下放了workspace/symbol等功能，觀望他們之後還要來回拉鋸多少次。

自己用就可以做很多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-*等外部工具能做的，未來可能會統一成一個 命令行/clangd refactor框架。
  • 刪除默認的-fms-compatibility -fdelayed-template-parsing -fms-extensions。這是原作者revert我的一個commit
  • 刪除goma clang的特判。提供給clang的命令行應該做儘可能少的變換，用戶自行添加選項適配自己的項目。
  • 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::幾個字
  • import_pipeline file_contents file_consumer等文件，我也比較茫然，每次要改都得重新理論下。這裏流程太複雜了，不清楚能怎麼簡化。

Resurrection Sunday

12 个赞
2

happy forking

1 个赞
3

支持一个 顺便问下，新的 cquery 是不是更改了配置方式？我一打开 .c 文件就显示 cquery 已经被杀死。现在已经退回到 19 号的那个版本了

4

我也参与过开源软件，但都是公司支持的，而且只自己维护，没有做社区化。 相比之下，觉得你这个才是真正的开源，牺牲自己的时间，只为他人方便。精神值得敬佩，为你点赞！

5

用了这么久了, 觉得还是很好用的. 感激你所做的一切, 给你点赞.

6

希望能在论坛里征集一下大家的问题和意见, 优化体验.

目前主力还是irony mode, cquery用的不多, 不过发现很多细节跟irony差别较大, 但体验并不好, 这个转变比较难受, 希望能跟irony的风格接近或一样, 毕竟irony是前辈, 已经有很多用户.

其中一个就是include的补全. 类似这样的细节, 可以让大家讨论一下, 那种体验最好.

7

我觉得你可以在readme说一下，你fork的原因。毕竟你这个不是用来contribute upstream的，而是自己单干了

8

cquery.el裏有

(defcustom cquery-project-root-matchers
  '(cquery-project-roots-matcher projectile-project-root "compile_commands.json" ".cquery")
  "List of matchers that are used to locate the cquery project roots.
Each matcher is run in order, and the first successful (non-nil) matcher
determines the project root.
A `string' entry defines a dominating file that exists in either the
current working directory or a parent directory. cquery will traverse
upwards through the project directory structure and return the first
matching file.
A `function' entry define a callable function that either returns workspace's
root location or `nil' if subsequent matchers should be used instead.
"
  :type '(repeat (choice (file) (function)))
  :group 'cquery)

項目根目錄的匹配是個很難的問題。C++項目更明顯一點，參見https://github.com/emacs-lsp/lsp-mode/issues/293。主要難點：

  • subproject文件的根希望識別爲主項目(不然沒有全局的交叉索引信息)
  • build system有生成文件，比如生成了build/a.cc你再放個build/compile_commands.json，a.cc弄不好就歸爲屬於build/“項目”了
9

谢谢帮助…

11

问一下，开发需要链接clang的工具时，都是事先在自己机器上编译好，然后项目在clang的tools/extra下开发么？ 如果想链接二进制安装的库(/usr/lib)，怎么构建呢？

12

我自己用的构建命令行是：

mkdir release
CXX=clang++ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_LINKER=/usr/bin/ld.lld -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DSYSTEM_CLANG=On -DCMAKE_PREFIX_PATH="$HOME/Dev/llvm/static-release;$HOME/Dev/llvm/tools/clang" -Brelease -H.
cmake --build release

塞了本地编译clang+llvm得到的libclang.so.7

% tree ~/Dev/llvm/static-release/lib/ -L 3

├── clang
│   └── 7.0.0
│       ├── include
│       └── lib
├── libclang.so -> libclang.so.7
├── libclang.so.7 -> libclang.so.7.0
└── libclang.so.7.0
13

很久没关注这个话题了，用的还是 cquery v20180302。现在写些 helloworld，也不敢贸然更新，不知道会不会 revert 掉某些 commit，从而导致问题？

迁移至 ccls 有什么需要注意的？

14

现在几个月功能上都没有太大区别了(libclang的瓶颈，cross navigation榨不出更多实用的功能了)

v20180302相比目前版本：

  • bundled clang 从5.0.1到6.0.0了
  • completion行为有点区别(#能补全出#include #ifdef等而不是直接给header list)
  • SymbolKind定义的值有区别，用semantic highlighting会感受到颜色不匹配，不用无影响
  • commit a781292d417c09eea33997b5ba20e400f2cd070f ，“Fix #487 dead loop in hierarchical .cquery”
  • 他们往ycmd方向发展了，弄platform arguments和自动调用clang++ -E -v -xc++ /dev/null获取系统include path
  • 可以用cmake构建了

ccls清理掉一些用不着的文件，合并了一些src/文件，不能带来功能上的好处

1 个赞
15

Mac 下也可以编译了：homebrew-ccls

16

cquery/ccls 保存文檔後觸發textDocument/references很容易發現

  • 相同位置的引用重複出現
  • 引用丟失

原因我基本也知道，import_pipeline太複雜，cache_manager 在多indexer時有race的(一種比較良性的race，synchronize到主線程querydb時有問題)

前天把import_pipeline.cc query.cc大幅精簡了，但問題還沒有根除(我可能需要徹底刪除cache_manager.cc)。

有朝一日還是要用上Clang C++ API (我要好好學習llvm全家桶)

我對clangd的未來仍然很擔心。

http://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.html Apple的人號稱要加入開發(會導致clangd討論的人更多更難把方案落實，畢竟Google的人的想法是支持自己的超大原始碼庫+支持開源專案；我們只用後者)。而後者需要的 memory index一直沒有做好，可能會做好但是記憶體用量很大(看看他們現在堆的好幾個StringRef)。workspace/symbol被合併了，然而現在這個狀態多加功能只會導致以後改起來更麻煩。

1 个赞
17

配置完没有 头文件补全了吗 也不显示 函数的提示啊

18

头文件补全可以用company-c-headers，然后读取ccl的命令行参数来获取补全路径。

19

这个哦，去看说明原来是支持cpp的啊，以前一直以为只有c

20

主要是cpp得自己设置头文件路径。有个(ccl-file-info)可以读命令行参数，加个-E -v - < /dev/null就可以获取头文件路径了，反正我目前是这么做的。

21

cquery會自動運行clang++ -E -xc++ /dev/null -v，獲取系統include path。這個功能很容易出問題，且其他方案(如company-c-headers可以做得更好)。因此我不想在ccls中支持

// cquery/src/config.h
  // Should system include directories be discovered/extracted by running
  // |clang++ -E -xc++ - -v|?
  //
  // System includes are necessary to resolve system/stl headers like <vector>.
  //
  // cquery will try a number of different compilers for system include
  // extraction. If there is a compiler mentioned in your project, that will be
  // used. Otherwise, cquery will use cquery-clang, and then the system-wide
  // clang++ or g++ will be used.
  bool discoverSystemIncludes = true;

三天前大幅精簡了import_pipeline.cc，刪掉了不必要的time manager cache manager，保存後情況改善很多