0

因此，情况是由于一些不可预见的后果，我需要使用 Visual Studio 2019（据我所知的最新版本，16.7.3）为 Windows构建 Cap'nProto（ https://capnproto.org/ ）。

正如您从下面的屏幕截图中看到的那样，编译器对代码非常不满意，以至于它在第 2616 行给出了内部编译器错误，其中有一个非常复杂的宏扩展为自动模板噩梦。

错误截图

宏本身是：

#define KJ_CASE_ONEOF(name, ...) \
    break; \
  case ::kj::Decay<decltype(*_kj_switch_subject)>::template tagFor<__VA_ARGS__>(): \
    for (auto& name = _kj_switch_subject->template get<__VA_ARGS__>(), *_kj_switch_done = &name; \
         _kj_switch_done; _kj_switch_done = nullptr)

我的第一次尝试是手动修复此事件（以及此文件中的下一个事件，其中包含在 for 之外提取两个变量定义的行，并添加一对额外的范围（实际上不触及宏）但下一个编译阶段显示，可悲的是，这个宏实际上在应用程序的任何地方都使用了。顺便说一句，这个策略奏效了，编译器不再崩溃了。

但是由于战略性地设置了恶意中断，（很容易）按照上述策略重写宏被证明比我想象的要困难一些。

现在，我可以报告错误并等待 Microsoft 修复它的编译器，但是考虑到我需要这个编译器......昨天这不是一个选项。

Capnproto 在他们的网站 ( https://capnproto.org/install.html#supported-compilers ) 上声称他们支持 Visual Studio 2017，遗憾的是这对我来说也不是一个选择。

我选择的另一个解决方案是询问社区是否有人对如何重写该宏有任何其他想法，以便稍微扰乱宏生成的代码，而它仍然具有相同的含义，只是表达方式不同（我尝试添加更多变量，**dummy = &kj_switch_done但它仍然会导致编译器崩溃）。

有任何想法吗？

4

1 回答 1

1

这是KJ_CASE_ONEOF()中围绕 VS2019 ICE 的工作，现在正在代码审查中，希望很快能合并到 master

于 2020-09-16T18:33:51.540 回答