因此,情况是由于一些不可预见的后果,我需要使用Visual Studio 2019(据我所知最新版本16.7.3)为Windows构建Cap'nProto(https://capnproto.org/)。
从下面的屏幕快照中可以看到,编译器对代码非常不满意,在某种程度上,它在第2616行给出了内部编译器错误,该行中有一个相当复杂的宏,扩展为自动模板梦m。
宏本身是:
#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
行中,但仍会导致编译器崩溃)。有任何想法吗?
最佳答案
这是一个Work around VS2019 ICE in KJ_CASE_ONEOF(),现在正在代码审查中,希望很快能被合并到master中