fork了cquery => ccls emacs-ccls

感覺很矛盾,一方面希望自己做的東西能有廣泛受衆(比如一個學長因此找到了我),另一方面,項目關注多了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

10 个赞

happy forking

1 个赞

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

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

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

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

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

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

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

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.jsona.cc弄不好就歸爲屬於build/“項目”了

谢谢帮助…

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

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

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

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

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

现在几个月功能上都没有太大区别了(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 个赞

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

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 个赞

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

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

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

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

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,保存後情況改善很多