原文

-J编译器开关

接着,Dennis说,据他所知,添加-J是为了避免串导入被用作恶意软件载体.在他看来,串导入风险不大.

Martin谈到了Symmetry在他们的代码基中使用-J,atila告诉他是如何在雷鬼中大量使用它的.Dennis建议按根目录对待-J目录,并添加其子目录到搜索路径中.Martin和atila都表示,(在导入式中包含完整路径时)编译器已允许从-J目录的子目录导入串.

DMD后端

Dennis说,因为DMD后端与DMC和C++编译器(DMC)共享,因此,更改后端不能破坏DMC,并要检查.
既然ImportC很重要,是否仍需要不破坏DMC的维护DMD的后端,或让DMD后端仅针对DMD,并及时冻结DMC.
沃尔特说他已放弃了维护DMC.DMD后端现在不必再维护DMC.Dennis说,这会更容易维护后端,可删除源码中DMC相关注释.沃尔特同意了.

Dennis说,构建DMD时,后端使用一些,使用extern声明而不是D导入的翻译后的头文件.应该更改它们为更现代的D.沃尔特同意了.他没有利用分离来重构,但不久前已停止支持DMC后端后向移植的更改.

丹尼斯接着注意到有一堆版本(Mars)和版本(scpp)块,并问,是否可更改为版本(全部)和版本(无),然后再删除它.
Walter说他并不急于大规模的重构,但是是的,这很好.除了修复错误之外,他已有一段时间没有在后端工作了,且在此过程中逐渐更改为D风格.
他举了最近涉及修复内联错误时的一些更改的示例.
Walter表示,ImportC可能永远不会取代DMC,主要是因为DMC也编译C++代码.Dennis补充说,DMC仍提供16位支持.

更新:Dennis已提交了几个PR,从pt1开始,从后端删除函数原型.

马蒂亚斯

他有个开放的PR来修复与-preiview=in相关的CTFE错误,这里.
在PR线程中,Martin指出了参数式求值顺序的问题,Martin解释了在存在异常时,要如何处理析构顺序.
这导致Mathias掉坑里面,因为似乎有时CTFE中不调用析构器,所以PR停滞不前(在我写这篇文章时它仍开放).他计划完成它,来使-preview=in可默认启用.

拉兹万

修复问题

Razvan报告说,他主要修复编译器中的段错误,并发现C++混杂器中有一些ICE.他提交了一些PR来解决这些问题.特别是这个,他不确定修复是否正确.他请马蒂亚斯看一看.

Razvan也一直在修复一些nosharedaccess问题.他看到了atila报告的回归,但除此外,没有其他开放的nosharedaccess问题.他预计那里会有更多的八哥,而阿蒂拉预计他会找到一些.

BetterC链接器错误

接着,Razvan说他一直在研究BetterC的错误.然后,他描述了与CTFE中实例化模板相关的问题.

当模板包含运行时勾挂时,如果它仅CTFE且不生成代码,则在BetterC中没有问题,但有时在运行时相同的实例化,前端没有抓住它,会导致链接器错误.
Walter针对BetterC中@nogc函数相关问题的修复发现了该问题,并且PR还引入了回归.

Razvan随后描述了相关BetterC问题.有时,编译器会试从语义上分析生成的函数体,并在出现故障时按禁止标记该函数.
然后,他描述了BetterC中可能出现的一系列后果:生成函数最终实例化了使用DRuntime勾挂的模板,而即使禁止了实例化它的生成函数,也实例化它,并最终会导致链接器错误.

他说,根本问题是编译器目前无法在缓存模板实例后重新分析它们.他不确定如何最好地解决该问题.他说他不喜欢编译器按特例的处理方式:如果在ImportC中,请这样做,如果你在BetterC中,请这样,如果在CTFE中,请那样操作.

阿蒂拉和马丁点头表示同意.马丁说,这是的BetterC的主要问题.它充满了前端和胶水层的黑客.

马丁说,他在BetterC中看到了许多缺少符号错误.其中大多数与编译器优化的删除模板有关.他描述了它的工作原理,并指出,使用-allinst开关时,没有该情况.
他建议在BetterC中出现链接器错误时,先要尝试它.-allinst工作时,问题可能只是删除模板.

关于重新分析模板实例,Martin说编译器确实试这样做.
仅如下工作时,

static if(!_traits(compiles, ...)

而

static if(!__traits(compiles, something) { 
// 干something失败的测试
}

这就是该有趣问题的原因
分析模板实例化失败,且编译器遇见第二个实例化时,它会不断地试,有时因为前向引用问题(他为万恶之源,并说这是前端遇见的主要问题)而工作.

阿蒂拉同意不应按特例工作.应该达到BetterC闲着.如果代码不需要运行时,则就不应链接它.
不必特殊操作即可获得该行为.-betterC开关唯一应该做的,就是告诉编译器分析代码,并告诉你在BetterC中它是否管用.其他一切都不变.

沃尔特说,问题根源是,在BetterC中使用CTFE.CTFE总是使用GC分配.阿蒂拉说,在BetterC中这应该是可以的,拉兹万同意了.
Walter说,问题是:编译器如何知道只在CTFE中使用该函数.

最终,Martin说根本问题是BetterC在前端而不是在胶水层中检查(TypeInfo,ModuleInfo等),这对CTFE来说是个问题.
如果是在胶水层中完成的,则是个麻烦,因为每个编译器实现都必须这样,但至少仅当要生成编码时,才会遇见问题.

Dennis问是否应该有个检查Semantic3和codegen的单独BetterC趟.马丁说,这至少是个选项.阿蒂拉重申,BetterC应该闲着.Martin同意这是好的长期目标,但在到达那里之前,需要摆脱模块及类型信息.

atila说如何表示仅CTFE函数.与其添加新的UDA,为什么不直接使用in(__ctfe)合约?这样编译器因为不必查看函数主体,就更容易分析了.
Walter说他会用

if(__ctfe} { // 
    代码 
} else assert(0)

atila认为合约比这更漂亮,Walter同意了,它确实避免了新语法的需求.

atila说,因为它按"我只在CTFE工作,所以不要调用我"声明函数合约,这也是对的.这甚至不是黑客.丹尼斯认为因为仍可取它的地址,这有点黑客.
你必须按静态条件对待它,但__ctfe是运行时变量.沃尔特认为这值得探索.

Martin建议使用if(__ctfe)作为模板约束,而不是用in合约.Dennis喜欢该想法,但Walter说他不想开始把模板约束应用至普通函数.
这会是新的语法,而这就是in(__ctfe)所避免的.atila说它表明模板函数,而不是想要的.

更多关于BetterC的信息

接着,Razvan提到了TeodorDutu把DRuntime勾挂转换为模板的工作.该努力的一个期望副作用是,应该使代码在BetterC中更有用,但有时,在这些模板中完成实际工作表明,要调用C库(memset,memcpy等).没有标准C库时,这是个问题.

Walter说,BetterC应在有标准C库时使用,因此可依靠这些函数.

这触发了更多BetterC链接器问题及如何缓解的讨论.最后,马丁说BetterC是一把大锤,因此有前面Razvan提到的特例代码.应努力减少该情况.

Walter说应该考虑重新设计功能,这样就不需要TypeInfo了.atila认为总是应该选入TypeInfo.现在可用编译时反射来生成所有这些.

Martin说,在此可用新的模板勾挂(LDC中的GC到栈优化需要些额外的工作).问题是关联数组.他们大量使用TypeInfo.他提到了SS实现,据他所知,它没有TypeInfo.也许最终可用它.

马丁

DIP1000问题

遇见使用std.algorithm.all相关问题.在@safe代码中,可避免遍历有opEquals的结构数组,而用户端对此无能为力.
他说是Phobos的错误,但他怀疑这是编译器推导属性问题.他还没有时间化简并提出问题.

atila说,这里的主要要点是处理弃用非常耗时,尤其是在第三方代码中时.此时,很难找出为什么按@system而不是@safe推导弃用代码.
也许应该重新考虑DIP1000.至少,对称性正在投入资源,但大多数人会放弃.

Dennis说他更喜欢尽量不用中域(return scope),而是让编译器推导它.当有人因为编译器错误而导致中域错误时,打开BuildKite项目来修复相关问题很烦人.

DIP1008问题

接着,Symmetry的一个项目使用DIP1008.这是对的,因为它是个与DotNet代码交互的项目,它也有一个GC,当另一个GC活动时,无法可靠地挂起另一个GC,因此他们一般避免使用D的GC.
他们仍需要抛异常,因此使用-preview=dip1008.现在,想静态链接该项目到主项目中.问题来了,(大约300个)所有拉入的配音项目都用它编译.
这会导致乱码异常消息,因为非DIP1008相关代码不会阻止异常逃脱其域.

Martin提出了,用另一个DIP1008实现,唯一的变化是禁止nogc检查抛式.他说,团队告诉他,因为异常,他们可把垃圾留在周围.
这项工作很容易.他建议按实验实现,如果适合他们的代码基,则将其上游化.这表明不依赖malloc和引用计数,只是从GC分配且永远不会释放它.因为,在该项目中始终禁止GC的.

沃尔特说,他有点抱歉D有异常.它们是无休止问题来源.事后看来,使用可选类型更好,但当时他只是遵循C++和Java.
可从标准库中删除异常,以便可无异常的可靠使用它.另外是继续在标准库中,尽量减少使用GC.

Dennis说,在Phobos中,有些地方的异常,在API中根深蒂固.他特别引用了区间,你可在其中解码文本并获得UTFException,或解析数字可能会触发ConvException.
要更改此设置,需要所有用户解包整数,解包代码点等.atila说可用行为与现在一样的alias this,如果用户忘记解包,则抛异常.丹尼斯说这是个有趣的想法.

Walter举例说,在std.path中使用std.algorithm.chain,来避免在连接路径并返回时分配内存.
标准库中是否有类似帮助避免内存分配和异常,但他还未深入研究如何消除异常.
阿蒂拉说,他一直在考虑复制(HerbSutter)零成本C++异常的想法.他说,基本思想是,保留语法的同时摆脱异常.PDF的链接.

沃尔特

Walter一直暂停实现新功能,并处理ImportC错误列表.最大问题是系统头文件中编译器扩展的普遍性,而且几乎总是不必要的.
咆哮:一个头文件在FreeBSD上编译,但不能在macOS上编译,另一个头文件在macOS上成功,但在FreeBSD上失败,微软是最严重的罪犯等.
ImportC旨在成为标准C编译器,但你不能使用标准C编译器编译系统头文件.必须实现很多扩展来使之正常工作.

从好的方面来说,在这方面取得了很大的进展.如,他已想出了如何用几行代码实现语句式.他很震惊,只有几行字就可了,并对结果感到满意.
因此,在让ImportC编译所有这些随机.h文件方面取得了良好的进展.
他想尽快删除ImportC错误列表,并转向其他错误.几周后,他在论坛上发布了有关此内容的文章,并呼吁帮助查找有问题的C头文件.

然后他重申,想减少Phobos中的GC和异常,并消除TypeInfo等依赖项.越彻底越好.
沃尔特最后说,他有很多工作要做.他说他感谢Razvan和Dennis帮助他的拉动请求.他们帮了大忙.