哈Ha！ 许多人已经开始为新年假期做准备，购买礼物，有人正在计划漫长的新年假期。 在JetBrains，我们仍然是发布产品发布的热门时机。 今天，我急于与您分享有关我们最近发布的C和C ++跨平台开发环境-CLion 2019.3。的新闻。
此发行版的主要目标是，尽管听起来听起来有些可悲，但它的质量。 我们决定专注于困扰用户很长时间的问题-首先是编辑器的生产力和响应能力，其次是错误，缺陷和非常流行但缺少的功能。
首先，简要介绍此发行版中最重要的内容：
- 改进了编辑器的速度和响应能力，主要是在基于Clangd的引擎中实现了自动补全功能。
- CMake中的Ninja生成器，默认CMake设置和其他设计模型改进。
- 与调试器集成的更新。
- 用于在头文件和源文件之间切换的新操作。
- 更准确的代码分析：虚拟功能的新检查，以及CMake和Doxygen注释中的拼写检查。
- 支持C ++ 20标准中的概念。
- 代码覆盖率指标。
- WSL2，Microsoft的格式和命名约定，VCS支持更新等。
我们将在下面详细讨论，但是如果您准备立即尝试，请进入并从
我们的网站下载构建。 与往常一样，可以免费试用30天。
编辑表现
根据统计数据，我们的许多用户同意发送给我们，CLion中最常用的操作是
自动完成 。 我们决定将重点放在他身上，以使其反应更快。 为此，我们基于Clangd在IDE中已经存在的自动完成提供程序中又添加了一个。 底线是所有供应商并行工作，一旦第一个结果准备就绪，CLion就会显示选项的下拉列表，并根据需要继续加载其他选项。
当然，我们想了解这种混合方法是否能带来好处。 测量结果表明，在简单项目中，CLion供应商和基于Clangd的供应商的速度相差不大。 但是在LLVM，Qt，Boost，Eigen等复杂项目上，来自Clangd的前一百个结果似乎要快得多。 自己判断：
在CLion英语博客上的另
一篇文章中了解有关测量的更多信息。
在其他重大改进中，值得注意的是IDE启动时间的平台加速。 它是通过在开始时并行处理许多进程，重新组织开始时加载的类并优化macOS上的字体加载来实现的。 要加速的具体数字取决于环境，汽车，平台和其他因素的设置。
在CLion中，非常遗憾的是，仍然存在用户界面挂起。 我们尝试根据原始问题将它们分组，然后一个接一个地解决。 因此，在此版本中，我们修复了以下情况：在打开的“用法”视图中，在切换到声明时，在重命名
#include指令时，在使用面包屑和安全删除时以及在其他情况下的冻结。 用户界面暂停仍然是我们最紧迫的问题，因此我们一定会在将来的版本中继续进行此工作。
最后，
重命名加速重构 。 这种重构不仅可以重命名代码中使用的名称，还可以重命名字符串文字和注释。 但这并非总是必要的，并且在IDE用户指示将重命名哪些特定用途之前进行了名称搜索。 这导致长时间找不到流行名称。 现在，您可以先仅通过代码选择搜索，然后再开始搜索本身。 为此，请转到“设置” /“首选项” |“设置”。 编辑器 一般| 必须禁用重构“启用就地模式”。 在这种情况下，当调用重构时（在Windows / Linux上默认为Shift + F6，在macOS上为⇧F6），CLion将立即打开“重命名”对话框，您可以在其中指定搜索参数：
CMake设计模型改进
在这里，许多人肯定已经在等待对Makefiles支持的公告。 但是到目前为止，只有
半自动方法可以通过编译数据库进行集成。 仍在开发更多的本机支持，但是在此发行周期中，我们取得了长足的进步，我们有机会在2020年3月底左右为下一个版本2020.1提供新的支持。
但是，我们获得了期待已久的机会来支持CMake-能够指定任何CMake生成器，包括用户期望的
忍者生成器！ 以前，我们使用Makefile和类似的生成器，因为我们分析了生成的文件（更准确地说，它们是
-G“ CodeBlocks-Unix Makefiles” ，在Windows上是
-G“ CodeBlocks-MinGW Makefiles”和
-G“ CodeBlocks-NMake Makefiles” ） 现在，您可以在CLion的CMake配置文件中指定任何生成器：
仅当使用CMake版本3.15和更高版本时才有可能，因为它是通过CMake File API实现的，并且可以在所有平台上远程运行WSL / WSL2。
我注意到，Xcode和Visual Studio这样的生成器是多生成器，也就是说，它们为所有类型的程序集（Debug，Release等）生成文件，但是CLion将仅使用在中指定的程序集类型。 CMake配置文件。
此版本还引入了
默认的CMake设置 。 这意味着对于CLion中的所有新项目，您可以使用相同的预定义设置，例如CMake生成器或用于生成CMake的目录。 可以在文件|文件中指定设置。 其他设置| 新项目的设置...
在CMake项目模型的重要改进中，仍然值得指出的是，即使项目中存在其他无效配置，也可以重新加载有效配置。 如果您已配置了当前不可用的多个远程配置，但希望至少重新加载本地配置，则此功能很有用。
调试器集成更新
在调试器中，我们决定修复与用户最相关的问题和不足。 首先，CLion现在
从项目目录读取
.gdbinit / .lldbinit 。 如果您想自定义一些调试器设置或添加漂亮的打印机，但仅用于特定项目，这将很有用。 以前，您必须在用户目录的调试器配置文件中指定这些设置。 现在，您可以配置特定于项目的这些参数。 但是，要使此功能起作用，必须在调试器本身中的用户目录级别的设置中启用此行为（了解如何对
GDB执行此操作以及如何对
LLDB进行操作 ）。
在Linux和macOS上可以与LLDB集成。 在新版本中，我们将内置的LLDB升级到9.0版，并同时在全球范围内审查了所有内置的漂亮打印机。 因此，两个平台上的标准容器的性能都得到了显着提高。 可以在我们的
英语博客上找到详细的比较。 值得注意的是，在macOS平台上，
libc ++库的处理要比
libstdcxx好得多 。 这似乎与这些库在该平台上的流行程度相对应，但是如果您在macOS上使用
libstdcxx ，请在注释中告诉我们更多有关此类情况的信息。
现在，CLion有
几个选项可用于远程处理项目和调试。 从完全远程选项（当项目的组装和调试都在远程计算机上进行时）到仅远程调试项目的选项。 对于第二种情况就是这样，我们向CLion-
Remote GDB Server添加了另一种配置。 与长期的
GDB远程调试不同 （是的，我们没有名字，我们同意），CLion在新配置中自行构建项目（也许您需要配置交叉编译设置），将可执行文件下载到远程计算机，然后在指定的gdbserver下运行程序。 现在，旧的配置现在更适合于复杂的选项，此时代码位于一台计算机上，汇编代码位于第二台计算机上，调试位于第三台计算机上。 或者，如果无法交叉编译。
转到头文件/源文件
是的，它做到了！ 最后，我们添加了一个单独的操作来在头文件和酸文件之间切换。 与旧平台
转到相关符号的主要区别是什么？ 事实是，作为常见的平台操作，
转到相关符号会尝试非常准确，并选择最正确的选项。 这既冗长又不总是C ++的正确。 新的“
转到标题/源”操作的行为有所不同：
- 如果在500毫秒内没有一个正确的选项，则将出现一个合适选项的下拉列表，用户可以从中选择最合适的选项。
- 如果用户已经从该文件导航过，那么他导航到的文件将位于列表的顶部。
- 列表中的其他名称将是来自相同目录的文件。
- 然后，匹配的声明和定义的搜索结果将继续。
值得注意的是搜索功能（因为我们的用户已经使用了它）-现在对直接包含/包含文件进行搜索。 这是一个必要的时间限制，以免混淆来自不同目标的具有相同名称的字符。
代码分析
CLion的代码分析器中出现了新检查。 它捕获了从构造函数或析构函数调用虚拟函数时的情况。 为什么这不好，已经
讨论了很多 。 现在，CLion警告此类情况：
拼写检查器是集成开发环境的组成部分。 我们都犯了拼写错误，因此我们的同事很难阅读代码和注释。 因此，IDE突出显示此类错误是很好的。 在此版本中，我们在CMake文件和Doxygen格式文档注释中包括了拼写检查：
减少拼写错误-更具可读性的代码！
C ++ 20中的概念
我们的团队正在为基于Clangd的语言引擎付出很多努力。 全球C ++社区正在积极开发Clang。 在此版本中，我们共同努力-在Clang实验分支的支持下，该分支支持由Saar Raz开发的C ++ 20中的概念，并将其倒入我们的Clangd分支中。 因此，我们通过CLion中的Clang分析器的概念和基本检查突出显示了代码：
但是我们并没有就此止步。 在基于Clangd的引擎中，我们实现了一些自动完成的有用情况，检查概念的使用，为概念
重命名重构，导航和搜索操作，
转到“定义和
查找用法” 。
自动完成受限制的模板参数：
自动
std::is_same<Other, T>和
same_as<T, U> ：
您可以在
英语博客中阅读有关我们在概念上的共同合作的更多信息。 还有CppCon 2019报告的录像带，其中Saar Raz在Clang展示了他的概念实现以及我们在CLion中有关概念支持的联合工作。
代码覆盖率指标
代码覆盖是CLion用户一直在等待和要求的机会。 在上一发行版中，AppCode团队朝着这个方向开始工作，在这一方面，我们为CLion中已经存在的跨平台C ++选择了它。
CLion代码覆盖率指标通过与llvm-cov / gcov工具集成而起作用。 在这种情况下，您可以运行单元测试和常规配置，并根据它们的执行情况，计算某些代码行的执行频率。 如果需要，几次发射的结果可以概括为一个整体。
您可以在特殊的Coverage窗口中直接查看结果：
...或在编辑器的左侧。
好，最重要的是：要使此工作正常，您需要传递特殊的编译选项：
- 对于GCC：
-fprofile-arcs -ftest-coverage或--coverage 。 - 对于Clang：与GCC相同的标志，或
-fprofile-instr-generate -fcoverage-mapping 。 差异仅在于组装覆盖率指标的方法。
为什么CLion本身不传递这些参数？ 主要是因为我们有一条规则，不得干扰编译过程。 是的，如果不使用CMake，并不一定总是将这些参数传递到哪里。 但是现在我们正在考虑将来如何自动执行此类情况的选择（消毒剂也有类似的问题）。
您可以在我们的
在线帮助中阅读有关编译选项以及在CLion中显示指标的更多信息。
其他改进
此版本的其他重要改进包括：
- 支持WSL2子系统。 CLion中的设置与WSL第一版中的设置相同。
- 支持Microsoft提供的格式和命名规则。 此样式可与Google，LLVM，Qt，GNU，Stroustrup和其他在Settings / Preferences | 编辑器 代码样式| C / C ++。
- IntelliJ Rust插件更新（我们的英语博客上的详细帖子专门针对这些更改）。
- VCS支持IntelliJ平台的更新，用户界面和其他更改。
演示版
最后，关于CLion 2019.3新功能的传统视频（英语）：
感谢您阅读到底！ 当然，您有问题，希望，错误报告和想法，我们正在评论中等待他们！ 与往常一样，我们将很乐意回答和讨论您的想法。
您的JetBrains CLion团队
发展动力