檸檬哥整理了50本計算機相關的電子書，關注公眾號「後端技術學堂」，回覆「1024」即可獲取，回覆「進群」拉你進讀者技術交流群。
本文首發個人微信公眾號，歡迎圍觀點選閱讀原文
最近遇到一個有意思的bug，是關於VSCode編輯器外掛的，最近趕專案時間非常緊，說實話在這時平常用的順手的IDE出問題非常影響心情。這就像是你開在高速路上，吃著火鍋唱著歌，突然輪胎爆了，你說氣不氣人。
不過在找bug和推動修復bug的過程有點意思，通過一系列嘗試最終定位和復現了bug，並且給這個專案的微軟官方倉庫提了issue，最終在最新版本得到了修復，把這個有趣的過程分享給大家。
也給大家演示一下如何通過提 issue 的方式參與到開源專案中，當然，參與開源專案的方式有多種，你可以給專案貢獻原始碼，甚至作為大使幫助推廣專案，找到專案的bug進而提issue也是一種參與方式，總之先參與進來，才能發現開源的樂趣！
詭異的報錯
上週，又是一個在公司的夜晚，好像和平常沒啥區別，檸檬哥在加班ing，飛快的敲打著自己的機械鍵盤，熟練的用 VSCode 瀏覽著專案原始碼，順手按下F12+Shift 想看看這個函式在哪些地方被引用了，詭異的事情發生了，這VSCode它竟然不聽使喚了，查不出引用的結果了，並且終端提示如下錯誤：
快速資訊操作失敗: FE: 'Compiler exited with error - No IL available'
快速資訊操作失敗: FE: 'Compiler exited with error - No IL available'
一開始我以為是單個工程解析問題，不慌，問題不大。
後來換了個工程嘗試，不論我如何的反覆摩擦我潔白的鍵盤帽，始終不能出來查詢引用的結果介面，這時才發現，粗大事了。工欲善其事必先利其器，雖然進度有點趕，還是停下來康康是誰在搗鬼？
老讀者應該知道我的開發環境都是遠端開發環境，之前我寫過幾篇介紹如何用VSCode搭建遠端開發，以及配置開發環境的文章，可以說是VSCode重度愛好者，感興趣我是怎麼遠端開發的可以瞭解下歷史文章：
繼續前面說的，如果不能查詢引用的話，那會對編碼和閱讀原始碼帶來很大的不便，這個功能算的上是IDE的基礎功能了，如果連這功能都廢了，那我要你這VSCode有何用？如果不能修復的話我估計要跑拋棄它，用回 Visual Studio 或 CLion。
但是VSCode遠端開發是真的香，並且已經習慣了VSCode操作，在放棄之前還想掙扎下，看還能不能搶救？不過如果實在不行，也沒時間死磕，專案還要繼續，大不了換個 IDE 繼續玩，甚至都想好了以面再也不說VSCode香了。
一起來找bug呀
雖然這個外掛不是我寫的，但我按照一般程式設計師排查bug的思路，通過下面幾個步驟一步步來找到問題原因，最終並推動官方的版本更新來修復，一起來看看吧。
軟體問題？
首先，來看看是不是VSCode版本升級導致的問題。按下面的操作，我檢查 VSCode 的版本資訊。
仔細核對版本號和官網的區別，對比問題出現的時間前後都沒有升級過新版本。
OK，應該不是 VSCode 版本升級導致的問題。
配置問題？
既然不是 VSCode 升級版本導致的問題，那就奇了怪了，白天還好好的晚上突然咋就不行了呢？難道這外掛也不想加班了？我陷入了沉思，不過馬上靈機一動，會不會小心改了C++環境配置檔案出了問題？
這裡有個知識點記下，要考。VSCode中有一個叫c_cpp_properties.json的配置檔案，這個檔案主要用於配置C/C++工程的基礎資訊，比如：預定義巨集、指定編譯器路徑、預定義標頭檔案搜尋路徑等。
{
"configurations": [
{
"name": "Linux",
"includePath": [
"${workspaceFolder}/**",
"/lemon/handsome/thirdparty/**",
"/lemon/smart/inc/**"
],
"defines": [],
"compilerPath": "/usr/bin/gcc",
"cStandard": "c11",
"cppStandard": "c++14",
"intelliSenseMode": "gcc-x64"
}
],
"version": 4
}
機智如我，肯定是這個工程的include 搜尋路徑配置的有問題，才導致查詢引用失敗了，趕緊去檢查一眼配置檔案，於是熟練的敲下Ctrl+Shift+P 查詢所有命令和配置（敲黑板！這個命令很常用，背下來），輸入關鍵字c++ Edit 果然匹配到了配置檔案，開啟就是上面的配置檔案。
但是看起來檔案路徑好像是對的，不管了，死馬當活馬醫，先全部刪除重新配置一遍看看效果，一頓操作之後興奮的檢查有沒有用，然並卵，還是那個該死的提示 FE: 'Compiler exited with error - No IL available'，心態有點崩。
環境問題？
發現這個問題確實有點詭異，走到這一步，我幾乎可以斷定是Linux開發環境出了問題，但是不確定是我的機器環境問題還是 Linux下 VSCode 本身問題，那怎麼辦呢？先來證明是Linux下才出的問題吧！
我就嘗試不開遠端開發模式，把遠端Linux機器上的工程直接拉到宿主機本地資料夾，然後用VSCode開啟宿主機上的本地工程，它竟然工作的很好，完全沒有出現什麼錯誤提示，到這，已經完全可以確定這個bug只在Linux環境下出現了。
夜已深，起來喝杯水，看了下時間，加班班車快到末班了。
事已至此，看來真的要關掉遠端開發，在本地重新配置所有工程了，表面上還是勸自己再找找原因，沒事，問題不大。
外掛問題？
喝完水，我坐下來繼續想，會不會是C++擴充套件出了問題呢？大家都知道VSCode只能說是一個編輯器，能夠讓他變身C++ IDE完全是有背後的C++外掛或者叫擴充套件的支援。
就是下面黑黑的這貨，它是VSCode能夠支援C++開發背後的男人，眾所周知VSCode是微軟親兒子，看看這個外掛作者Microsoft 看來也是微軟自家人開發的外掛，釋出之前肯定是經過嚴格測試的，問題不大。
不過現在誰也不能相信，即使是微軟自家的外掛也不能信任了，假裝冷靜分析一波。
經過嚴謹的思考（然而並沒有），最終決定拿出程式設計師必殺技：重啟試試，解除安裝重灌。
點選解除安裝，解除安裝完成，點選安裝，重灌完成，重啟載入，一氣呵成。
興奮的搓小手手，準備再次見證奇蹟，WTF，問題依舊沒能解決，實話告訴大家，做到這個份上，檸檬哥可以說是已經非常的絕望了。
正道的光
真相只有一個
不管了先回去睡一覺，夢裡啥都有，沒準第二天白天又有了新思路。
果然第二天我又有了新想法，雖然解除安裝重灌外掛沒用，但我們程式設計師還有最後一招：回退版本！
是時候表演真正的技術了，資深程式設計師肯定懂的，常在河邊站哪有不溼鞋，版本釋出出問題，趕緊回退保命是常規操作。
那我們就有理由懷疑：微軟在釋出這個外掛最新版本的的時候把一個重要特性搞掉了。但是這東西發都發出去了，也不是服務端後臺服務說回退就能回退的，這個外掛如果真是bug也只能等下一個版本修復，還是我們自己來操作回退吧。
找到外掛，按下面方法來執行回退操作：
檸檬當時回退的時候還沒有出最新的修復版本，裝的是有問題的1.0.0版本的外掛，看這個版本號應該是個較大改動的大版本，出問題也正常。
關鍵是可以看到這個版本的釋出時間點剛好是我發現bug的時間，這回感覺離真相越來越近了，至少在時間上是吻合的有底氣了點，那有理由懷疑是這個外掛出了問題，回退到上一個穩定版本0.29.0
這次奇蹟真的出現了，「查詢引用功能」它回來了！而且也沒有出現FE: 'Compiler exited with error - No IL available'的報錯提示，為了進一步確認自己的判斷，我又把外掛升級到1.0.0版本（穩了），果然又出現了剛才的問題。
至此，這個bug算是定位成功，並且可復現驗證，暫時的解決方法是回退到上一個穩定版本。
離線安裝
另外提醒一下，公司其他同學也遇到這個問題，我在幫其他同學解決這個問題的時候，發現有些人直接升級可能會有網路問題，導致線上升級不了，報錯：
這時候可以去上面我發的官網下載離線版本外掛安裝包，下完之後，按照下面的操作升級即可，效果和線上升級一樣。
注意了，由於一些眾所周知的原因，如果你打不開官網或者下載速度很慢，可以加文末我個人微信，備註「下載外掛」我發給你已經下載好的外掛。
推動版本更新
提issue報bug
這就完了嗎？當然不是。費了我這麼大功夫找出來的bug，不要再浪費其他人時間了，所以我決定去微軟這個外掛的官方倉庫去給他們提 issue，這裡給不瞭解 Github 開源專案的同學科普下什麼是 issue ? 上課了，看黑板！
Github專案的 issue 用於團隊協作管理，可以把將要實現的 feature 或者要修復的 bug 通過提 issue的形式記錄下來，所以我們如果發現開源專案的bug，可以通過給開源專案提issue的形式報告這個bug，提醒專案團隊修復跟進。
這裡給出微軟官方C/C++ 外掛的github倉庫地址：https://github.com/microsoft/vscode-cpptools
我去寫下了下面這個issue ，雖然是英文描述的，大家應該都能看得懂我就不逐字翻譯了，計算機相關的英文來回就那麼幾個單詞，看多了就會寫，大意就是描述了我遇到的bug和問題出現時的環境配置資訊，方便他們定位和復現問題。
issue 標題： C/C++ Extension 1.0.0 some feature Not working When using in Remote-SSH remote development #6176
並且詳細描述了我遇到的問題，其實經過上面一頓操作，檸檬肯定是他們這個版本有問題，但還要友好溝通推進問題儘快解決才是目的，寫程式碼的何苦為難寫程式碼的，沒有直接說他們有問題，而是委婉的問了下 I wonder if there is a problem with this latest Extension ? 哈哈
完美解決
我提issue的時候是中午吃飯的時候12點左右，那時美國那邊應該還是凌晨，我想肯定沒這麼快有回覆了，國外程式設計師小哥都還在睡覺呢，怎麼也得早上上班才能看到之後回覆，但是萬萬沒想到在下午5點左右就收到了回覆，果然神速。
不過，等等，好像哪裡有點不對勁，注意上面圖中具體時間已經沒顯示了，只是顯示一個 2 days ago，在我看到訊息通知的時候有點詫異處理這麼神速，好奇去翻開處理issue老哥的 github 主頁介紹。
回覆的這位是微軟VS Code C++ Extension的軟體開發工程師，然後定位是美國的Redmod, WA ，特意去查了當時的美國時間是05:03，這位老哥是在凌晨5點鐘處理的這個bug。。。這也太優秀了吧，果然大佬們都是半夜寫程式碼不用睡覺的，看到凌晨五點的太陽我信了。
覆盤一下
到了這裡，這個bug從出現在我的機子上，到定位查詢，最終修復算是完美的解決。這裡附上官方的版本連結：https://github.com/microsoft/vscode-cpptools/releases ，裡面有提到本次修復的bug。
按照最新的1.0.0 版本釋出說明，如果你使用 Linux/MAC 版本的VSCode 或者像我這樣用遠端開發的方式從宿主機使用Linux版本，可能會遇到我文中說的bug，我是在0.29.0自動升級到1.0.0發現的bug，於是給1.0.0版本報了個issue，微軟官方在1.0.1版本修復了上述的bug，一張圖看清時間線。
檸檬在這裡建議：正在使用0.29.0版本外掛的同學不升也沒啥大問題，但如果你用的是1.0.0版本，那就要注意了，這個版本在本文描述的場景下是有問題的，還是及時升級到最新版本為好。
如果文章對你有幫助，答應我不要白piao好嗎？「點贊、評論、轉發」激勵我持續創作。
可以微信搜尋公眾號「 後端技術學堂 」回覆「1024」獲取50本計算機電子書，回覆「進群」拉你進讀者技術交流群，文章每週持續更新，我們下期見！
