本文主要是介绍2312d,d的10月会议，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
原文
拉兹万
Razvan从他最近在内联中遇见的一个问题开始,他不知道如何解决.一般,当A模块导入B模块并从B调用函数时,如果B的目标文件没有传递给链接器,则最终会出现链接器错误.
如,在命令行上使用A.d编译并省略B.d时.但是,当内联调用函数时,则不会触发链接器错误.他怀疑这是一个优化.
他发现该行为,破坏了使用内联标志的BetterC构建.他解释说,内联在语义3后运行,但因为B不是根模块,因此会完成一些额外语义工作,然后最终会出现TypeInfo错误.
他的第一反应是,这是个侵改,不应语义分析内联.但是,如果更改此设置,则可能会在其他地方导致链接器错误.
沃尔特说这是他第一次听说它.为什么不直接链接B模块?或添加它为根文件?为什么对BetterC来说是一个特殊的问题?对前者,Razvan说这是修复错误的方法.
然后他问Walter是否同意,不应语义分析内联.沃尔特说他不知道,因为他没有调查过.他不记得会语义分析内联.
然后,Razvan查询是否每个人都同意使用和不使用内联标志编译应该产生相同结果.沃尔特说不一定.如果函数是内联的,则无需链接它.
要链接它,则必须按根模块添加它.所以他不明白为什么这是一个问题,为什么这对BetterC来说是一个特殊的问题.
Steve说,必须语义分析内联代码.因此,他问Razvan是否在谈论一些其他语义分析,比如分析未使用代码.
Razvan解释说,他谈论的是,当导入模块不是根模块时,内联必须分析内联代码.
Martin提到了一些LDC链接器标志,这些标志需要对原本会在外部链接的事物额外的语义分析.他说,如果某个东西是根模块,则都会对其分析,但是如果你只是编译模块A,并且它决定内联另一个不需要语义分析的函数,则是的,他不确定自己是否明白这里的问题所在,但他可确认他们在几周前遇见了问题.他们遇见了与内联相关的链接器错误,但这与单独的编译无关.
他说这是以后的话题.
Walter指出,如果B模块中的内联函数调用了B模块中的其他函数,则如果没有链接B,你会看到链接器错误.这就是问题吗,马丁说这不是他们说的问题.
它是一个包含所有代码的单元测试运行程序,因此不应有未定义符号.
Walter要求Razvan澄清他看到了什么样的链接器错误.Razvan表示,这与BetterC代码中的TypeInfo生成有关.
最根本问题是在不应该分析语义时,分析了语义,并生成TypeInfo.如果用-betterC编译,但不用-inline,则不会看到错误,但如果同时使用两者编译,则会看到错误.
Walter说,好吧,这是一个TypeInfo问题.为了弄清楚这一点,他必须跟踪代码,以了解此时为什么在B模块中生成TypeInfo.他想不出一个理由.
Razvan建议另一个解决方法是,仅从根模块中内联函数.沃尔特说这不行.你无法拥有好头文件库.他说,正确解决方法是,确定为什么,在不应生成TypeInfo时生成它.
Martin表示,LDC在TypeInfo上没有这类问题,因为它对它们有不同的发射策略.他建议DMD采取同样的路线.对类,总是在包含类声明的模块中生成TypeInfo.
据他所知,这与DMD相同.只在结构不同.添加到结构中的特殊TypeInfo成员都发出到包含结构的目标文件中,但实际的TypeInfo在访问时会延迟发出,但会从codegen层发出.
因此,他们避免了CTFE需要TypeInfo的所有麻烦,因为它在每个需要它的模块中都是懒生成的,它会在运行时执行实际代码中访问它.
可在代码生成层,而不在语义分析阶段,推导实例化.
Steve理解,如果带BetterC且没有-inline链接,调用需要TypeInfo的函数,则表明因为需要TypeInfo,被调函数并不是真正的BetterC.
Dennis认为,想在库中,调用仅CTFE函数时,就会这样,如,调用仅在CTFE中用GC的Phobos函数,并内联插入Phobos代码到BetterC代码中.
他说,本质上,BetterC是一堆黑客,而前端内联则有点黑客,长远看,它们都应该消失.Steve总结其为:当CTFE函数使用运行时功能时,BetterC不能CTFE,这是个长期存在的问题.
Walter问Razvan是否存在Bugzilla问题.沃尔特问公关是否有效,拉兹万说没有.
更新:Bugzilla问题和拉取请求都已关闭,因为该问题不再重现.
丹尼斯
Dennis想知道DMD中错误接口的未来会怎样.他们一直在努力使用错误接收器,这样就不仅是直接打印到控制台,并且接口只是个printf的薄包装器.
它出现了一些问题,且因为接口太有限,试修复失败了.Walter想要个简单而不是复杂的接口.
因此,丹尼斯想知道中间可有位置:因为目标之一是改进错误消息.
沃尔特说他同意该目标.在他最近拉取请求中,他一直不让错误消息处理器提供多个接口.并说明要简化诊断错误消息打印机.
他回忆说,他同意Iain删除添加到错误接收器中的复杂性,但还没有开始.错误接收器有两个目的:简化接口,并使其可与DMD库一起使用.
然后,库可提供自己的接口来执行期望工作.所以他想保持简单.DMD库将很简单,因此可简单实现LSP.
随后讨论了当前实现问题,toChars和toPrettyChars的使用,关于截断和格式等.一个重要观点是,Walter说,在消息到达错误接收器前,应该预先设置好所有自定义格式.
语法高亮等,应该由错误接收器调用的事物来完成.但是,错误接收器自身不应决定格式和高亮.
结果是,Dennis说会试新的toChars方法,看看他能走多远.
亚当.
讨论微软如何处理.NET版本问题.他总结了下:
1,在11月结束的,为期一年的发布周期.
2,在2月份,开始第一次预览,三个月的准备阶段.
3,共有七次预览.
4,接着是两个候选发布版本.
路易斯
CTFE整数溢出
路易斯首先提出了,Weka在编译时遇见的一个问题:无法知道整数是否会溢出.期望能对此发出警告.他正在使用DMD库和LDC插件来开发linter.
他想在linter中对此发出警告,但是无法勾挂常目录.
Walter说,检查整数溢出的问题是,有时想要整数溢出.路易斯同意并说,可以在真正需要时忽略它,但大多数时候不想要这样.
他说,对编译器来说,或至少对编译时,可像Clang和GCC那样清理检查整数溢出.运行时,可用GCC和LLVM支持的清理程序.
他说他已就此开了个公关,丹尼斯告诉他这是已定义行为.他同意这一点,但在某些用例中,它并不受欢迎.他明白沃尔特不喜欢警告.
即使不会加进编译器,他也想有个方法查询是否毒化常量,然后就可用linter来处理.它与Razvan在DMD库上工作相吻合.
Walter说,首先,有时确实需要整数溢出.其次,在一堆不在源码的位置上加整数,如,在结构成员偏移上的加.
并不清楚,是否应该检查这些地方的整数溢出.还没有解决,很多整数溢出问题.另一个问题是它不适合DMD的后端.
编译时和运行时的行为要一致.
路易斯说,如果DMD可在编译时完成,他们就可在运行时检查它.最好,两者都可以.Martin指出,Weka已有了自己的编译器分支.
沃尔特说,通过常数折叠和运行时会有不同行为.这不好,但如果Weka对此感到满意,则可在他们的编译器分支中实现它.
他说Steven已指出,可显式使用checkedint.其中一些是在DMD源中完成的.显式检查了容易溢出的位置.
Timon指出,CTFE浮点行为与运行时不同.沃尔特说,这是个难以解决的已知问题.他做了个公关来修复它,但破坏了很多东西,所以退缩了.
因此附带讨论了一些浮点差异,如何明确指定实按依赖实现,如果想要可移植性,请使用双精,Walter说,可用自己的模拟器替换所有浮点计算,但它很慢.有时,只需要忍受差异.
讨论又回到了易受影响的整数溢出,这时应如何显式检查,总是启用它的性能成本等.路易斯指出LDC有一个标志,可在运行时启用溢出检查.
Walter建议应该也可在编译时有个标志来启用它们,并认为这会是个好主意.建议路易斯和马丁谈谈这件事.
推导属性漏洞
第二个问题是,单独编译时出现的推导属性错误.有时候,它不正确.标准库有问题时,他无法解决它.
沃尔特说,这一般是由前向引用问题引起的.路易斯同意了,并说他试修复它,但一直无法解决.沃尔特说丹尼斯对此有一些想法.
他想交换默认值.丹尼斯说他已试过了,但遇见了问题.查询函数类型时,它要求知道属性.
以后进一步讨论该问题.
AST节点中的语义分析
接着,路易斯有个与DMD库相关的主题.他说,他一直在为ldc的lint制定一些lint规则.
他发现很多AST方法在底层,都在搞语义.如果有项目可把它们分开,那就太酷了.这是编译器大重构的一部分.
Walter说,他一直在慢慢努力,最小化AST功能,提取不需要的非虚函数.这很耗时,但也是前进方向.
路易斯说,从LDClint角度来看,主要问题是他们想查询AST,但不想改变它.目前,某些查询(如在测试是否存在@nogc时),在未找到该属性时,会跑语义.
他不想在这些查询函数中运行语义.如果是前向引用,只需告诉它.
他继续解释说,LDClint使用的是LDC的AST,如果在语义和codegen之间,如果改变了AST,且有依赖未改变的东西,就会有未定义行为.
阿蒂拉说,常会对此有所帮助.路易斯同意了.但从重构角度来看,语义应该与查询分开.如果在查询,需要知道,它不变.
阿蒂拉指出,这正是常的目的.有人抱怨它太严格了,但这就是它的重点.
Walter说,分离功能,以便在AST中只有const函数可用的想法非常好.
史蒂文
Steve首先指出,在D1中,你可把int数组字面转换为ubyte来设置类型,如cast(ubyte)[1,2,3,4].
他说Discord中有人证明cast(ubyte)[10000,2,3,4]同样,但10,000最终变成了10,000的ubyte截断值.
他记得这只是个设置类型的手段,而不是为了让你可丢弃信息.他觉得这很奇怪,想知道是否应该解决它.
Walter让他提交一个Bugzilla问题,Steve说应该有一个.
接着,他说他在编译时的关联数组代码中,发现了一个重大缺陷,Dennis已为他合并其到DMD中.hashOf函数的操作方式,与TypeInfo上的toHash不同.
会导致从它们中得到的哈希值有时不同,导致运行时的错误表示.他说他有个解决方法.
最后,他提出了code-d,这是由JanJurzitza(Webfreak)维护的D的VSCode扩展.史蒂夫说,工作时很好,但是有很多奇怪东西导致它坏了,这里.
除了code-d之外,哪些是重要的或关键的D项目这是需要解决问题之一.
代码猫,小孩学习D编程
串插值
接着,他提出了串插值,说已研究了很多年了.他说John和Andrei写了一个非常好的提案(YAIDIP)这里,解决了他们在Symmetry遇见的现实问题,可惜D语言没变.
阿蒂拉说,问题是约翰和安德烈从未完成过该提议.亚当说,实现是有效的,在本可继续前进且富有成效,不应关心提案细节.
阿蒂拉不知道有它的实现.他最后一次听说他们还在努力.Adam说他已为从事的另一个DIP编写了一个实现,并撤回了它以支持YAIDIP,但核心是相同的.
阿蒂拉问实现在哪.亚当说在某处DMD公关中.
阿蒂拉
他发现有个导入std.file的单行文件需要200毫秒才能编译,这太疯狂了.他要搞清楚.
这只是导入中的语义分析.甚至没有生成目标文件.同一台机器上,还试了仅使用#include<iostream>的C++编译,它耗时400毫秒.
他说,比C++快两倍是远远不够的.沃尔特同意了.
需要解决标准库的循环导入问题,但他并不是100%相信这会大大缩短这些构建时间.
史蒂夫想知道这是否与CTFE不必要时的运行有关.阿蒂拉说肯定.就像有超过一百万个静态foreach.
需要一段时间,除了有个更好的CTFE引擎外,你无能为力.但因为甚至没用导入文件中的符号,不应花这么长时间.
Walter指出,模板并不仅是通过导入来分析语义的.它们必须扩展.因此,std.file中的某些内容正在扩展模板.他怀疑与std.uni等有关.
沃尔特
Walter说,他一直在重构前端来简化它,使其更易理解和实现DMD即库.
路易斯关于拥有const的AST函数想法是个好主意.
它在设法最小化几个模块的依赖.这样更易使用编译器.他计划继续这样做,路说,表达式模块是DMD中最大文件之一.
沃尔特说,名单上有它.他一直在考虑把它拆分为两个文件.
除此外,仍在不断修复错误并稳定语言.
会议结束时,Razvan问是否还有补充的,Timon说他最近参加了几次编程比赛.注意到,他的D方法一般是所有参赛者中最简洁的.
沃尔特鼓励他在论坛上写一两段关于它的文章,并在其他地方宣传它.
这篇关于2312d,d的10月会议的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
