MSVC和Visual Studio 代码诊断的未来

我们正在努力改进 MSVC 和 Visual Studio 中的诊断体验。 我们从 Visual Studio 2022 版本 17.3 开始这项工作，虽然还没有开发完成，但我们想在这里分享早期的进展。

动机与原则

新的 C++ 特性（如 Concept 和 Range）为更具表达力的代码和定义更好的 API 提供了机会。 然而，为了充分利用它们，集成开发环境需要对代码进行更好的诊断，以便查明和解决代码约束问题。

正如开发者社区中的许多人所指出的那样，我们知道，在代码诊断这个领域，我们还有很大的改进空间，我们现在正在积极投资这一领域。

我们的开发倡导者 Sy Brand 向 WG21 提交了一篇论文，其中讨论了编译器诊断的关键原则，以及如何改进 C++ 编译器的最新技术。 我们使用本文档作为我们工作设计的指导。

作为第一步，我们正在研究编译器，以确保它收集所有可用信息，并能以一种工具友好的方式输出，以便日后使用。 我们还在 Visual Studio 中添加了新的诊断可视化功能，以便更轻松地导航和理解大的代码错误。

编译器的变化

1. 模板实例化上下文的最后一条消息现在显示发生错误的文本列。

2. 编译器现在列出函数调用的所有候选并解释每个候选失败的原因。

3. 未满足的关联约束的错误消息将扩展为详细说明未满足哪些基础约束。

源代码

17.2 中的编译器输出

17.4 中的编译器输出

IDE 的变化

17.4 中的 IDE 体验（内置查看器）

17.4 中的 IDE 体验（SARIF 查看器扩展）

编译器更改通常会生成更多文本，并且有时会使理解它们变得更加困难。 我们正在尝试使用新的编译器选项将诊断结果输出到静态分析结果交换格式 (SARIF)。 输出将由 Visual Studio 加载以可视化消息的层次结构，以便于导航。

目前，单击 Visual Studio 错误列表中与 SARIF 输出相关的错误将弹出一个带有可折叠诊断信息的弹出窗口。 我们还在开发 SARIF 查看器扩展，以提供更丰富的体验。

技术细节

以下是编译器现在关注的三个领域。

一般基础设施（源代码位置）

错误消息中的列信息是在 Visual Studio 2017 中添加的。但是，它有时会丢失或不正确。

> 缺少列信息通常是因为编译器并不总是在函数之间传播列信息。

> 有时会产生不正确的列信息，因为编译器没有在嵌套上下文中维护必要的信息（例如，实例化模板特化）并且其值被错误地修改。

我们将继续审核操纵源位置的 API，以确保它们传播和维护列信息。

仍然存在列信息不正确的情况（这在编译器生成的函数中很常见），所以如果你遇到这些情况，请告诉我们！

重载解析

重载解析的错误消息取决于函数是全局函数还是成员函数，是否是运算符，并且对可用候选者的数量敏感。 这会导致不一致，例如：

> 编译器通常只列出它尝试过的最后一个候选者。

> 编译器有时会列出所有候选者，但没有解释每个候选者失败的原因。

> 编译器经常忽略模板候选。

我们现在调整这些场景中的行为以更加一致：我们总是列出包括模板在内的所有候选者，并解释每个候选者失败的原因。

Concept（未满足的关联约束）

以前，编译器仅针对未满足的关联约束发出一条通用消息。

现在，编译器将发出导致给定失败的所有相关约束。 其中一些会有解释，而另一些则不会。

我们仍在研究后者，因为我们的大多数语义分析逻辑还没有将原因传播回调用者——约束验证逻辑只知道某些事情失败了。

总结

有了更加丰富的错误信息，妈妈再也不用担心我编写模板代码了。

从此，天书变成了儿童读物。

最后

Microsoft Visual C++团队的博客是我非常喜欢的博客之一，里面有很多关于Visual C++的知识和最新开发进展。大浪淘沙，如果你对Visual C++这门古老的技术还是那么感兴趣，则可以经常去他们那(或者我这)逛逛。

本文来自：《The Future of C++ Compiler Diagnostics in MSVC and Visual Studio》