如果你寫過(guò)一陣子嵌入式C/C或者折騰過(guò)Android NDK、樹莓派、自編譯工具鏈這類東西大概率有過(guò)這種體驗(yàn)編輯器里的C/C代碼一片紅跳轉(zhuǎn)定義永遠(yuǎn)不成功補(bǔ)全全靠手打。代碼在CI上能編過(guò)但編輯器就是“看不懂”。很多人第一反應(yīng)是配置不對(duì)或者編譯器沒選對(duì)實(shí)際上問(wèn)題往往不在編輯器而在你從來(lái)沒有告訴編輯器“這個(gè)項(xiàng)目的代碼到底是怎么編譯的”。clangd配合LSP協(xié)議正好是解決這類問(wèn)題的利器。clangd是一個(gè)基于Clang/LLVM的C/C語(yǔ)言服務(wù)器而LSPLanguage Server Protocol是它和編輯器之間的溝通協(xié)議。簡(jiǎn)單理解就是clangd負(fù)責(zé)真正讀懂你的代碼和編譯過(guò)程編輯器只負(fù)責(zé)把結(jié)果畫出來(lái)。這套組合不僅能解決代碼補(bǔ)全、跳轉(zhuǎn)、重構(gòu)這些問(wèn)題在交叉編譯場(chǎng)景下尤其好用——只要你能把交叉編譯的真實(shí)過(guò)程告訴clangd它就能讓編輯器“按目標(biāo)平臺(tái)的視角”看懂代碼。這篇文章就專門聊聊這件事怎么做以及我在實(shí)際項(xiàng)目里踩過(guò)的坑。1. 先搞清楚clangd和LSP到底解決什么問(wèn)題1.1 LSP是給編輯器安裝的“翻譯官”在沒有LSP之前編輯器要支持代碼補(bǔ)全、跳轉(zhuǎn)定義這些功能普遍的做法是每款編輯器各搞一套插件插件調(diào)用各自綁定的分析工具。問(wèn)題是每個(gè)插件寫一套鉤子千奇百怪Vim里的YCM用起來(lái)和VS Code里的IntelliSense完全不同換編輯器等于換一整套體驗(yàn)。LSP這套協(xié)議把這件事拆分成了兩端一端是語(yǔ)言服務(wù)端Language Server它獨(dú)立于編輯器運(yùn)行負(fù)責(zé)解析代碼、建立符號(hào)索引、響應(yīng)補(bǔ)全請(qǐng)求、報(bào)告診斷信息另一端是編輯器客戶端只需要按LSP協(xié)議發(fā)JSON-RPC請(qǐng)求就行。兩邊通過(guò)stdin/stdout或者socket通信互不依賴。這種架構(gòu)下一套clangd服務(wù)端可以同時(shí)服務(wù)VS Code、Neovim、Emacs、Sublime體驗(yàn)基本一致。我用Neovim寫代碼、用VS Code看工程的時(shí)候切換工具幾乎不用重新適應(yīng)因?yàn)檠a(bǔ)全行為、跳轉(zhuǎn)邏輯完全來(lái)自同一個(gè)clangd。1.2 clangd是從哪里來(lái)的clangd不是憑空出現(xiàn)的小工具它由LLVM項(xiàng)目組維護(hù)代碼庫(kù)在llvm-project的clang-tools-extra目錄下。它直接復(fù)用Clang編譯器前端的完整詞法、語(yǔ)法、語(yǔ)義分析能力這一點(diǎn)非常重要——其他某些補(bǔ)全工具是“猜”而clangd是“真讀”。Clang前端能解析的細(xì)節(jié)clangd同樣能消化比如模板實(shí)例化后的類型追蹤、宏展開后的符號(hào)狀態(tài)、基于SFINAE的重載決策。這意味著在復(fù)雜模板代碼里clangd的補(bǔ)全質(zhì)量明顯高于正則表達(dá)式掃描式的傳統(tǒng)方案。還有一個(gè)容易被忽視的優(yōu)點(diǎn)clangd內(nèi)置了Clang的AST(抽象語(yǔ)法樹)緩存和增量索引一旦后臺(tái)索引建完跳轉(zhuǎn)定義和全局查找符號(hào)基本是毫秒級(jí)響應(yīng)。相比之下用Ctags這種靜態(tài)標(biāo)簽的工具面對(duì)模板重載和條件編譯就會(huì)頻繁失效因?yàn)樗谒饕A段根本沒有做語(yǔ)義分析。1.3 為什么不是Ctags、Cscope或者商業(yè)方案先聲明我沒有否定Ctags/Cscope的價(jià)值在很多純C老項(xiàng)目里Ctags依然是最輕量的選擇。但對(duì)現(xiàn)代C工程尤其是大量使用模板、標(biāo)準(zhǔn)庫(kù)、第三方頭文件的項(xiàng)目Ctags只能做到“文本級(jí)符號(hào)定位”它不知道哪個(gè)重載函數(shù)才是你要跳的那個(gè)也無(wú)法理解宏開關(guān)導(dǎo)致的不同代碼分支。Cscope的calls調(diào)用關(guān)系、text文本搜索功能我至今還在用某些場(chǎng)景下比clangd還方便。但它的定義跳轉(zhuǎn)只認(rèn)文本索引模板實(shí)例化后的代碼、宏展開生成的符號(hào)它都無(wú)能為力。商業(yè)IDE的方案比如某些圖形界面的集成開發(fā)環(huán)境體驗(yàn)確實(shí)成熟但缺點(diǎn)是重、貴、跨平臺(tái)聯(lián)動(dòng)麻煩。而且它們大多內(nèi)置自己封閉的代碼分析引擎不能和命令行編譯環(huán)境、CI腳本無(wú)縫銜接。clangd的優(yōu)勢(shì)在于它是開源的、命令行友好的我手里無(wú)論是CI上的批量檢查腳本還是日常編輯器里增量補(bǔ)全都是同一套分析內(nèi)核。2. clangd“看懂代碼”的核心編譯數(shù)據(jù)庫(kù)2.1 編譯數(shù)據(jù)庫(kù)是什么為什么重要先說(shuō)結(jié)論clangd不是靠語(yǔ)法猜測(cè)來(lái)理解代碼的它是按照“整個(gè)項(xiàng)目被編譯時(shí)所用的真實(shí)命令”來(lái)建立模型的。這個(gè)“真實(shí)命令”的集合就叫編譯數(shù)據(jù)庫(kù)Compilation Database規(guī)范上對(duì)應(yīng)compile_commands.json文件。編譯數(shù)據(jù)庫(kù)里記錄著項(xiàng)目中每個(gè)源文件是怎么被編譯的用了哪個(gè)編譯器、編譯選項(xiàng)是什么、頭文件搜索路徑在哪里、定義了哪些宏、目標(biāo)平臺(tái)架構(gòu)是什么。文件格式很簡(jiǎn)單是一個(gè)JSON數(shù)組每個(gè)元素對(duì)應(yīng)一個(gè)編譯單元。[ { directory: /home/user/project, command: /usr/bin/arm-none-eabi-g -mcpucortex-m4 -mfpufpv4-sp-d16 -mfloat-abihard -I/home/user/project/include -DUSE_HARD_FLOAT -c source/led.cpp, file: source/led.cpp } ]關(guān)鍵就在這個(gè)數(shù)組里每一項(xiàng)的command和directory。clangd啟動(dòng)后會(huì)解析這個(gè)文件對(duì)每個(gè)源文件重建一個(gè)“虛擬編譯過(guò)程”然后把它對(duì)應(yīng)的代碼模型AST、符號(hào)索引、宏上下文保存下來(lái)。這也是很多人的誤區(qū)所在以為加了clangd插件就能自動(dòng)“看懂代碼”結(jié)果打開工程一片紅因?yàn)楦蚴琼?xiàng)目里根本沒有compile_commands.jsonclangd完全不知道用什么參數(shù)去解析每個(gè)文件。2.2 各種構(gòu)建系統(tǒng)生成compile_commands.json的方法不同構(gòu)建系統(tǒng)導(dǎo)出編譯數(shù)據(jù)庫(kù)的方式差異很大。我按實(shí)際使用頻率排個(gè)序CMake如果項(xiàng)目是CMake構(gòu)建最簡(jiǎn)單的方法是在配置階段加參數(shù)-DCMAKE_EXPORT_COMPILE_COMMANDSON。之后CMake會(huì)在build目錄下自動(dòng)生成compile_commands.json。時(shí)間緊湊的時(shí)候也可以直接改CMakeLists.txt里加一行set(CMAKE_EXPORT_COMPILE_COMMANDS ON)。這個(gè)方法最干凈因?yàn)榫幾g命令和構(gòu)建過(guò)程天然同步。Make/通用工具鏈老項(xiàng)目還在用Makefile的時(shí)候我推薦用bear這個(gè)工具。它可以攔截make執(zhí)行期間實(shí)際調(diào)用的編譯器命令自動(dòng)生成compile_commands.json。用起來(lái)很簡(jiǎn)單bear -- make -j8注意前提是項(xiàng)目此前必須完整編譯過(guò)一次而且最好把舊的build產(chǎn)物清理干凈否則bear只記錄到實(shí)際執(zhí)行的編譯命令增量構(gòu)建時(shí)可能漏掉很多文件。Bazel/BuckBazel可以配置--experimental_action_listener或使用相關(guān)插件來(lái)生成編譯數(shù)據(jù)庫(kù)不過(guò)更常見的做法是借助工具把bazel的action graph轉(zhuǎn)成JSON比如編譯工具鏈集中管理時(shí)直接解析bazel aquery導(dǎo)出。這塊配置稍重但值得一次性投入因?yàn)锽azel項(xiàng)目手寫編譯數(shù)據(jù)庫(kù)幾乎沒有可維護(hù)性。compile_flags.txt如果不是大型工程只是單個(gè)文件夾里幾十個(gè)文件可以手動(dòng)建一個(gè)compile_flags.txtclangd會(huì)讀取它作為全局編譯參數(shù)兜底。每行一個(gè)參數(shù)比如-stdc17 -Iinclude -Isrc -DUNIT_TEST這個(gè)文件功能比compile_commands.json弱很多不支持按文件差異化配置但勝在簡(jiǎn)單適合庫(kù)作者、演示工程、給外部用戶快速跑起來(lái)的場(chǎng)景。2.3 編譯數(shù)據(jù)庫(kù)的真正價(jià)值在于“代入”很多人以為編譯數(shù)據(jù)庫(kù)只是給clangd提供頭文件路徑這是不完整理解。真正價(jià)值在于“狀態(tài)代入”。舉個(gè)例子同一個(gè)源文件config.h在不同的編譯參數(shù)下解析結(jié)果完全不同。比如-DTARGET_A1和-DTARGET_B1會(huì)讓#ifdef分支走向不同代碼塊而clangd會(huì)根編譯數(shù)據(jù)庫(kù)為準(zhǔn)只索引當(dāng)前配置對(duì)應(yīng)的分支。這樣跳轉(zhuǎn)定義時(shí)你不會(huì)跳進(jìn)被預(yù)處理器排除的死代碼里變量補(bǔ)全也只會(huì)出現(xiàn)當(dāng)前宏?duì)顟B(tài)下合法的符號(hào)。我在一個(gè)同時(shí)支持STM32和PC模擬器的項(xiàng)目里靠的就是兩套CMake配置生成兩套編譯數(shù)據(jù)庫(kù)切平臺(tái)時(shí)只要切換clangd指定的compile_commands.json路徑編輯器里的宏定義、內(nèi)置類型、頭文件路徑馬上跟著變化而且所有錯(cuò)誤波浪線都是基于目標(biāo)平臺(tái)的真實(shí)編譯結(jié)果。這個(gè)感受在以前用文本級(jí)索引工具時(shí)是完全沒有的。3. 交叉編譯場(chǎng)景下clangd必須被“喂”正確參數(shù)3.1 交叉編譯為什么讓編輯器徹底“瞎掉”交叉編譯的本質(zhì)是用本機(jī)上的交叉編譯器生成目標(biāo)平臺(tái)比如ARM Cortex-M、MIPS、RISC-V的機(jī)器碼。工具鏈自帶sysroot、標(biāo)準(zhǔn)庫(kù)頭文件、架構(gòu)相關(guān)宏這些信息如果編輯器不知道它就只能用本機(jī)默認(rèn)的頭文件路徑去解析代碼。結(jié)果就是目標(biāo)平臺(tái)專有頭文件找不到報(bào)一堆紅色波浪線架構(gòu)相關(guān)宏如__ARM_ARCH沒有定義條件編譯分支亂選使用目標(biāo)平臺(tái)編譯器內(nèi)置的__attribute__或者特殊關(guān)鍵字時(shí)編輯器無(wú)法識(shí)別比如我在本機(jī)編譯一個(gè)使用ARM CMSIS頭文件的工程如果不告訴clangd編譯器是arm-none-eabi-g不提供CMSIS頭文件路徑它會(huì)嘗試用本機(jī)的GCC預(yù)定義宏去解析結(jié)果cmsis_gcc.h里的__ASM、__INLINE這些宏完全對(duì)不上整份文件全是錯(cuò)誤。這不是clangd不行而是沒有給它正確的編譯視角。3.2 .clangd配置文件實(shí)戰(zhàn)clangd除了讀取編譯數(shù)據(jù)庫(kù)還支持一個(gè)用戶級(jí)配置文件通常是項(xiàng)目根目錄下的.clangd用YAML格式編寫。這個(gè)文件里最常用的區(qū)塊是CompileFlags和Diagnostics。我的交叉編譯項(xiàng)目里.clangd配置長(zhǎng)這樣CompileFlags: Compiler: arm-none-eabi-g Add: - --targetarm-none-eabi - -mcpucortex-m4 - -mfpufpv4-sp-d16 - -mfloat-abihard - -Idrivers/device/include - -Iplatform/board/inc Remove: - -mno-unaligned-access CompilationDatabase: build/ Diagnostics: ClangTidy: Check: - clang-diagnostic-* - bugprone-* Remove: - llvm-header-guardCompiler字段強(qiáng)制指定編譯器名稱Add字段追加編譯選項(xiàng)Remove可以剔除某些會(huì)對(duì)索引造成干擾的選項(xiàng)。尤其注意Remove交叉編譯工具鏈會(huì)傳入一些本機(jī)無(wú)用、甚至?xí)?dǎo)致clangd解析出錯(cuò)的鏈接選項(xiàng)或者某些只有目標(biāo)平臺(tái)編譯器才認(rèn)識(shí)的flag如果這些flag混進(jìn)編譯數(shù)據(jù)庫(kù)clangd可能會(huì)把它當(dāng)成未知選項(xiàng)并降低分析精度。還有一個(gè)容易被忽略的配置是ResourceDir。clangd自帶的Clang資源目錄里的內(nèi)置頭文件stddef.h、float.h等通常不含交叉平臺(tái)的標(biāo)準(zhǔn)庫(kù)頭文件如果項(xiàng)目依賴目標(biāo)平臺(tái)的標(biāo)準(zhǔn)庫(kù)應(yīng)該在CompileFlags.Add里用-isysroot指向開發(fā)板的sysroot路徑并把該路徑添加到頭文件搜索路徑。3.3 一套代碼、多套工具鏈怎么管理交叉開發(fā)經(jīng)常遇到一套源碼要同時(shí)支持多個(gè)目標(biāo)平臺(tái)的情況。我當(dāng)前在做一個(gè)傳感器驅(qū)動(dòng)庫(kù)代碼要能跑在Cortex-M4、RISC-V和x86模擬器三套環(huán)境中。我采用的方式是在CMake里分別建三個(gè)build目錄build/ host/ - 本機(jī)編譯用于單元測(cè)試 cortex-m4/ - arm-none-eabi-gcc riscv32/ - riscv64-unknown-elf-gcc每個(gè)build目錄里都生成對(duì)應(yīng)的compile_commands.json。clangd默認(rèn)會(huì)從源碼根目錄往上遞歸查找compile_commands.json但也可以直接在.clangd里指定CompilationDatabase: build/指向特定目錄。切平臺(tái)時(shí)我只要改.clangd文件里的CompilationDatabase路徑然后重啟clangd編輯器里的代碼模型就會(huì)切換過(guò)去。個(gè)人體驗(yàn)這套流程比很多IDE的“切換工具鏈”功能都可靠因?yàn)樗行畔⒍紒?lái)自真實(shí)構(gòu)建系統(tǒng)不需要在IDE里再手工錄入一遍頭文件路徑和宏定義。3.4 關(guān)于Sysroot、標(biāo)準(zhǔn)庫(kù)和語(yǔ)言標(biāo)準(zhǔn)的一些經(jīng)驗(yàn)交叉編譯里最容易翻車的其實(shí)是sysroot和標(biāo)準(zhǔn)庫(kù)版本不匹配。clangd解析代碼時(shí)會(huì)用編譯數(shù)據(jù)庫(kù)里的-isysroot參數(shù)確定庫(kù)頭文件目錄。如果多個(gè)編譯環(huán)境共享一個(gè)源碼目錄我把sysroot路徑統(tǒng)一用環(huán)境變量定義在.clangd里寫死或用編譯數(shù)據(jù)庫(kù)里的選項(xiàng)展開。語(yǔ)言標(biāo)準(zhǔn)也要一致。交叉編譯器默認(rèn)的C標(biāo)準(zhǔn)往往是工具鏈發(fā)布時(shí)的默認(rèn)值而 clangd 默認(rèn)按自己編譯時(shí)的標(biāo)準(zhǔn)處理。比如 toolchain 默認(rèn)C14而 clangd 默認(rèn)C17差異會(huì)導(dǎo)致std命名空間里某些類是否存在都可能看錯(cuò)。所以.clangd里務(wù)必寫清CompileFlags: Compiler: arm-none-eabi-g Add: - -stdc14另一條經(jīng)驗(yàn)是統(tǒng)一-fexceptions、-fno-rtti、-fno-threadsafe-statics這類代碼生成選項(xiàng)。雖然它們?cè)谡Z(yǔ)義分析階段不像頭文件路徑那么關(guān)鍵但有些頭文件會(huì)檢測(cè)這些宏?duì)顟B(tài)比如__cpp_exceptions、__cpp_rtti并改變內(nèi)部接口定義所以還是要完整同步。4. 在VS Code/Neovim里落地實(shí)操4.1 VS Code停用IntelliSense啟用clangd插件VS Code是目前很多嵌入式開發(fā)者主力的編輯器配置clangd的步驟簡(jiǎn)單取舍卻很關(guān)鍵。首先安裝 clangd 擴(kuò)展擴(kuò)展市場(chǎng)搜索 clangd發(fā)布者是 LLVM 項(xiàng)目組。裝完第一件事禁用微軟官方的 C/C 擴(kuò)展ms-vscode.cpptools。不是它不好而是它默認(rèn)只使用自己的IntelliSense會(huì)跟clangd搶同一份代碼的解析權(quán)結(jié)果常常是兩個(gè)引擎給出的錯(cuò)誤提示疊加界面混亂跳轉(zhuǎn)也會(huì)被覆蓋。只保留擴(kuò)展里的調(diào)試功能可以但建議在設(shè)置里加上C_Cpp.intelliSenseEngine: disabled。然后在設(shè)置里指定clangd可執(zhí)行文件路徑{ clangd.path: /usr/bin/clangd, clangd.arguments: [ --background-index, --clang-tidy, --header-insertionnever, --compile-commands-dir${workspaceFolder}/build/cortex-m4 ] }參數(shù)含義說(shuō)明一下--background-index讓clangd在后臺(tái)構(gòu)建全項(xiàng)目索引首次會(huì)慢之后秒開--clang-tidy啟用Clang-Tidy靜態(tài)檢查補(bǔ)全和診斷會(huì)額外提示源碼風(fēng)格問(wèn)題--header-insertion控制補(bǔ)全時(shí)是否自動(dòng)插入頭文件我習(xí)慣關(guān)閉因?yàn)榍度胧酱a頭文件影響較大自動(dòng)插入經(jīng)常選錯(cuò)--compile-commands-dir直接指定編譯數(shù)據(jù)庫(kù)所在目錄比依賴自動(dòng)探測(cè)更可控VS Code下我還會(huì)開啟clangd.serverCompletion的singleFile模式對(duì)單文件小測(cè)試更快。4.2 Neovim原生LSP整合Neovim從0.5版本開始內(nèi)建LSP客戶端配置clangd非常順滑。我在init.lua里做的最小配置是這樣local lsp require(lspconfig) lsp.clangd.setup({ cmd { clangd, --background-index, --clang-tidy, }, filetypes { c, cpp, objc, objcpp }, root_dir lsp.util.root_pattern(.clangd, compile_commands.json, .git), init_options { clangdFileStatus true, }, })關(guān)鍵點(diǎn)是root_dir。如果你在項(xiàng)目子目錄打開文件clangd需要向上定位到編譯數(shù)據(jù)庫(kù)所在目錄。root_pattern里我把.clangd放在第一位這樣即目錄里沒有CMakeLists也能以用戶配置為準(zhǔn)。Neovim里我配合了一組快捷鍵vim.api.nvim_buf_set_keymap(0, n, gd, cmdlua vim.lsp.buf.definition()CR, {noremap true}) vim.api.nvim_buf_set_keymap(0, n, gr, cmdlua vim.lsp.buf.references()CR, {noremap true}) vim.api.nvim_buf_set_keymap(0, n, gi, cmdlua vim.lsp.buf.implementation()CR, {noremap true}) vim.api.nvim_buf_set_keymap(0, n, K, cmdlua vim.lsp.buf.hover()CR, {noremap true})這套鍵位下跳轉(zhuǎn)定義、查找引用、查看實(shí)現(xiàn)、懸停提示都走clangd補(bǔ)全由內(nèi)置的completion提供體驗(yàn)和VS Code沒有明顯差別。4.3 編譯數(shù)據(jù)庫(kù)的自動(dòng)選擇腳本如果像我一樣同時(shí)維護(hù)多套構(gòu)建目錄純手動(dòng)改.clangd路徑還是有點(diǎn)煩。我寫了個(gè)簡(jiǎn)單腳本監(jiān)控當(dāng)前bulid目錄名自動(dòng)生成.clangd里的編譯數(shù)據(jù)庫(kù)指向#!/bin/bash # 根據(jù)參數(shù)切換clangd編譯數(shù)據(jù)庫(kù)目錄 TARGET${1:-cortex-m4} cat .clangd EOF CompileFlags: Compiler: arm-none-eabi-g CompilationDatabase: build/${TARGET}/ Add: - -stdc14 Remove: - -mno-unaligned-access EOF echo switch clangd to ${TARGET}腳本執(zhí)行后重啟編輯器即可。在多平臺(tái)項(xiàng)目里這個(gè)切換時(shí)間從幾分鐘降到了幾十秒強(qiáng)烈建議交叉編譯開發(fā)者都建一個(gè)類似的輔助腳本。5. 實(shí)際項(xiàng)目里我踩過(guò)的坑和排查方法5.1 一打開工程全是紅色波浪線這個(gè)最常見90%的場(chǎng)合是compile_commands.json路徑不對(duì)或者根本沒生成。第一排查動(dòng)作在終端手動(dòng)執(zhí)行clangd --checksource/led.cpp這個(gè)命令可以打印出clangd實(shí)際使用的編譯參數(shù)和解析錯(cuò)誤。如果輸出顯示頭文件No such file or directory說(shuō)明編譯數(shù)據(jù)庫(kù)里頭文件路徑不對(duì)。此時(shí)不要急著改.clangd先檢查CMake生成的compile_commands.json里的路徑是否真實(shí)存在。另一個(gè)經(jīng)典坑是 build 目錄里compile_commands.json是用-DCMAKE_EXPORT_COMPILE_COMMANDSON生成的但CMake有一個(gè)毛病如果文件已存在且選項(xiàng)關(guān)閉時(shí)再次配置舊文件不會(huì)被刪除導(dǎo)致你看到的編譯數(shù)據(jù)庫(kù)是上一次構(gòu)建的殘留。我的習(xí)慣是每次配置都明確執(zhí)行一遍cmake -B build/cortex-m4 -DCMAKE_EXPORT_COMPILE_COMMANDSON并且檢查文件時(shí)間戳是否在剛配置后更新。5.2 clangd內(nèi)存占用太高交叉編譯項(xiàng)目的MPU宏處理單元配置往往復(fù)雜全項(xiàng)目索引時(shí)會(huì)吃掉大量?jī)?nèi)存。遇到特別大的模板庫(kù)比如Eigen之類的clangd常駐內(nèi)存超過(guò)2G也不稀奇。解決思路有兩個(gè)。第一限制后臺(tái)索引的范圍.clangd里設(shè)置Index: External: Limit: - 1GB這樣索引超過(guò)限制時(shí)會(huì)暫停低頻部分的緩存。第二使用--limit-results之類的參數(shù)控制單次請(qǐng)求返回量。但說(shuō)實(shí)話內(nèi)存占用高在大型項(xiàng)目里是語(yǔ)義分析的正常成本真要徹底解決只能減少同時(shí)打開的文件數(shù)或者關(guān)閉--background-index。5.3 宏定義不同步導(dǎo)致的詭異報(bào)錯(cuò)有一次我折騰一個(gè)搭配-DUSE_FREERTOS才會(huì)包含F(xiàn)reeRTOS.h頭文件的源文件結(jié)果clangd總是提示找不到FreeRTOS.h。我首先去查編譯數(shù)據(jù)庫(kù)確認(rèn)-DUSE_FREERTOS確實(shí)在command里但依然報(bào)錯(cuò)。最后用clangd --check逐條核對(duì)才發(fā)現(xiàn)編譯數(shù)據(jù)庫(kù)里命令是arm-none-eabi-gcc -DUSE_FREERTOS...而clangd在預(yù)處理器解析時(shí)遇到宏USE_FREERTOS1和USE_FREERTOS兩種寫法會(huì)產(chǎn)生差異。我手寫的宏值少了一個(gè)“等于1”導(dǎo)致#ifdef USE_FREERTOS成立但#if USE_FREERTOS 1不成立。這種問(wèn)題編輯器不直接顯示原因只顯示頭文件缺失浪費(fèi)了我不少時(shí)間。教訓(xùn)是交叉編譯中任何與宏定義、條件編譯相關(guān)的報(bào)錯(cuò)都要先回到#if的條件本身去看不要把眼光局限在報(bào)錯(cuò)行的頭文件路徑上。5.4 診斷信息里出現(xiàn)奇怪的#?和亂碼這類情況多見于使用了目標(biāo)平臺(tái)編譯器特定語(yǔ)法如ARM的__attribute__((at(...)))、TI的#pragma DATA_SECTION時(shí)clangd支持的解析規(guī)則與真實(shí)編譯器不完全一致。處理思路是把這些特異語(yǔ)法退出編譯數(shù)據(jù)庫(kù)。.clangd里加一條CompileFlags: Remove: - -fgnu89-inline或者把源文件里該平臺(tái)獨(dú)有的#pragma用__clang__宏包起來(lái)讓clangd保留可解析的代碼路徑#ifndef __clang__ #pragma DATA_SECTION(led_buffer, .rambuffer) #endifdouble-check這種改法的安全性真正的交叉編譯器不會(huì)定義__clang__所以源碼行為不會(huì)被影響而clangd可以跳過(guò)這段。5.5 切換編譯數(shù)據(jù)庫(kù)后舊診斷仍然反復(fù)clangd有后臺(tái)緩存切換編譯數(shù)據(jù)庫(kù)后可能仍在用舊的AST結(jié)果。遇到這種情況重啟clangd進(jìn)程最有效。VS Code里執(zhí)行clangd: Restart language serverNeovim里用:LspRestart。有時(shí)候還要?jiǎng)h掉緩存目錄rm -rf ~/.cache/clangd/index/做嵌入式項(xiàng)目的緩存路徑有時(shí)候會(huì)落到項(xiàng)目build目錄下需要翻一下.clangd和 clangd日志里的實(shí)際路徑。6. 后續(xù)還可以怎么擴(kuò)展我把這個(gè)組合用在幾個(gè)場(chǎng)景里越用越順手。第一個(gè)是CI腳本里的靜態(tài)檢查以前用真工具鏈做全量編譯檢查很慢現(xiàn)在可以在CI里加一個(gè)單獨(dú)的clangd --check步驟快速檢測(cè)頭文件路徑、語(yǔ)法錯(cuò)誤和Clang-Tidy警告反饋速度比完整編譯快得多。第二個(gè)是無(wú)人值守的注釋補(bǔ)全檢查clangd的結(jié)構(gòu)化補(bǔ)全能力比正則提取穩(wěn)定很多用來(lái)校驗(yàn)代碼注釋率挺合適。就是得提醒一句clangd再怎么好用也只是“分析代碼”的工具不會(huì)替你驗(yàn)證鏈接過(guò)程和內(nèi)存布局。交叉編譯的最終對(duì)錯(cuò)還得靠真實(shí)工具鏈的編譯鏈接和硬件運(yùn)行來(lái)兜底。編輯器的綠色波浪線只是讓你更舒服不是你的驗(yàn)收標(biāo)準(zhǔn)。我在實(shí)際使用中最深的體會(huì)是這個(gè)組合的上限取決于你對(duì)構(gòu)建系統(tǒng)的掌控程度——compile_commands.json寫得準(zhǔn)所有編輯器都能被clangd點(diǎn)石成金。交叉編譯的參數(shù)本來(lái)就亂抽一點(diǎn)時(shí)間把編譯數(shù)據(jù)庫(kù)整理干凈長(zhǎng)期做項(xiàng)目時(shí)省下的時(shí)間和煩躁情緒絕對(duì)值回票價(jià)。