我给VSCode报了个bug，微软工程师居然凌晨回复了...

柠檬哥整理了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重度爱好者，感兴趣我是怎么远程开发的能够了解下历史文章：

文章1

文章2

继续前面说的，若是不能查找引用的话，那会对编码和阅读源码带来很大的不便，这个功能算的上是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本计算机电子书，回复「进群」拉你进读者技术交流群，文章每周持续更新，咱们下期见！