2407d,2024d的四月会议
弗拉基米尔
提出了三个问题,他说这些问题不是优先事项,但一直是他的痛苦.他现在在工作中的代码基中遇见了它们,所以想确保至少在某人的关注上.
他强调,不是非常紧急.其中两个是生成代码错误,其中一个是返回.他说第三个很奇怪.
1,懒式不会抓本
2,[REG2.101.0]带临时和元组区间foreach的错误码
3,在IFTI时,未在闭包中展开类型列表(元组)这里
巴斯蒂安
巴斯蒂安首先说,他很高兴丹尼斯开始与SARC合作.然后,他向介绍了从Pascal到D的转换的最新情况.
他提醒,在2023年10月的会议上,他报告了他在分配中遇见的线程竞争问题,随后报告说它已解决.从那时起,他在Pascal集合的实现中遇见了问题.
这些是位数组,在分配方面实现有点草率,但现在也解决了.他说,@nogc属性帮助追踪分配位置.
他说,总体而言,前台良好.但是他注意到,在重载函数时,可考虑inout来理解常,不变和可变函数参数与返回类型,对闭包参数是否有@nogc,没有可比性.
特别是在opApply中.
丹尼斯说,这是个长期问题.MathiasLang对闭包的属性多态性有个DIP,且还有其他建议.但它们有点复杂,目前还没有取得关注.
马蒂亚斯说,是,对此有一个DIP,但因为一些边角,他对此没有100%的信心.
如果有人愿意接受它,他很高兴与他们讨论,但他不认为自己很快就会回到它.
Bastiaan说这不是个大问题,但特别是,如果想重载opApply,必须做两次,以考虑@nogc闭包和那些垃集的闭包.
Dennis说,有时使用模板,可为你的返回类型设置通用的模板类型.他不知道opApply是否支持它,但它应该支持.
Mathias说,模板很好,直到你要用类或虚函数,然后就会崩溃.
Walter要求Bastiaan就此提交Bugzilla问题,他说他会的.
马蒂斯
马蒂斯说,他一直在努力推动增量编译,因为每个人都在切换到32GB的笔记本电脑.他遇见的一个问题是,一旦你把一个D文件和其他一些文件一起传递给编译器,就无法孤立地重建该文件.
编译器会在其中插入一些符号,然后在另一个模块中丢弃这些符号,或相反.
他们一直在跟踪他们传递到哪个命令行的D文件来解决它.然后,单独重建该文件时,再重新构建其他文件.
所以他们把文件按一个集合,然后分成两个不同集合,然后构建它们.第一次,没有加速,但第二次看到了改进.
主要问题是内存使用.特别是如果他们把它分解得太远,且有八个DMD实例并行运行或传递相同模块.
他们一直在优化内容,这样在单个构建中有适量的模板使用量,并充分利用对象和模块缓存.如果他们传递相同模块八次,它可能会更快,但对内存使用来说并不好.
他在聊天中粘贴了一个Bugzilla问题,并说应该按低优先级对待它.
他说,问题是当你重建一个是前面更大的构建集的一部分对象时的情况.
他期望,一旦它得到解决,后面还会有三个问题在等着他.现在所拥有的似乎确实管用了.
他还指出模具连接器绝对令人惊叹.他说,使用Linux的人都需要试一下.它应该是分发的一部分,因为它非常快.
丹尼斯也认为mold很快.他补充说,ryuukk_发表了一篇论坛帖子,说如何用mimalloc而不是glibc的malloc来加快构建时间.丹尼斯说他还没有调查过.
Johan问Mathis是否可共享他所描述的构建系统.马蒂斯说,如果它成功了,会在论坛上写一篇工作原理.
Johan
他说,因为更新太频繁,他们跳过多个版本是很常见的,但最近开始升级到LDC1.37或1.38.他们会遇见常见的问题,但比他期望的要少,所以这是积极的.
他说,因为升级过程,最近可能注意到Bugzilla上有一些额外的错误报告.这些是针对没有简单解决方法的问题.总之,效果很好.
目前还没有完全无法解决或非常疯狂的问题,但目前,他们仍在修复编译错误的阶段,还没有达到运行的地步.他说,在过去,编译器升级会破坏二进制文件,但过去几次都没有破坏.
他说,Weka有太多的模板内省代码,似乎会触及了语言的每一个边角.每次编译器更新时,边角都可能有变化.他们对此非常敏感.
如,他说他们有有个常的opAssign覆盖的结构.然后在标准库的某个地方,它坏了.
有个针对opAssign的区间迭代器测试,然后它没有移动,而是memcpy对象,然后抱怨它无法复制到常内存中.
因此,它检查了赋值,并且因为允许对常对象的此opAssign覆盖,它通过了.
他有一个想法,应该制作一个测试文件,收集所有这些奇怪的"来自地狱的结构".然后,如果正在找一个烦人结构来测试,可查看该文件,其中有一堆结构.
该列表链接到导致每个结构包含其中的错误.
沃尔特说那太好了,这就是测试包的用法.Johan说,难点在弄清楚它是否是有效的代码.语言是否应该支持它,还是太疯狂了.
MathisBeer问他们如何处理opAssign重载,Johan解释了一下.这只是代码基中的一个地方,他们基本上使用插件来修复结构,来基本上都有尾常.
他说,一般他不去理解代码.有时不得不这样做,但他一般尽量避免深入代码,因为那样他可能会试修复它,然后遇见更改程序行为的问题.
因此,他一般会试用旧编译器来重现,看看这是否正确,或它是否真是个错误.
他说,值得一提,编译器现在,在静断上static assert(false, "message"),是直接static assert("message").
这在代码基中发现了个错误,真很高兴编译器抱怨它.但即使此时,也必须停下来弄清楚,及是否可在断定中添加假来修复它.
Razvan指出,他总是发现在opAssign上,拥有常或immutable的能力真很奇怪.他过去曾提及,但当时有些人在用它.
他们没有修改数据,而只是记录调用.他仍觉得这很奇怪,并认为不应允许不变或常.但是人们很疯狂,所以现在必须支持它.
Johan说DMD都无法编译Weka代码基,尽管他最近没有试过.他一直在努力将Weka的LDC和私有LDC间的差距降到最低,现在它非常小.
仅测试编译是否有效可能不再重要.因此,第一步是非常接近上游编译器可编译它.但是不要生成二进制文件,DMD无法编译其中有一些LDC特定的东西,所以可语义分析会很好.
他认为他们正在到达那里.然后可每月或每周一次编译检查.当然,不想它在每次DMD更新中都出现.即使在ldc,他们也没有.
他说,DMD和LDC最近的模板发射改变,对Weka来说是一个改进.过去需要修复或更改LDC,以匹配Weka构建系统对模板发射的期望.
这永远不适合上游测试.它只对Weka有效,一般无效.但现在,因为模板发射的这些上游变化,他们已显著改变了他们的构建系统.
所以也许现在上游LDC可编译Weka的代码基.他对测试二进制文件持怀疑态度.
Razvan说DMD没有在后端修改.大多数都在前端修改.如果在更改语义分析时能测试Weka,那就太好了.
Johan补充说,在新版本中遇见的二进制文件的一个大事件是,因为更改类布局,对象布局有变化.监听器字段移动到尾,这产生了意外的巨大影响.
该类事情在过去非常糟糕,以至于他们有工具来检查它.每个类和结构都是内省二进制布局来哈希处理的.如果有更改,生成系统会标记它.
在更深层次上,即使编译器在诸如更改填充等,它也应该标记.
他说,即使在LLVM更新中,或在更改优化标志时,也会发生该类事情,所以必须考虑的不仅是前端.
巴斯蒂安指出,现在的策略是,不想频繁地破坏事情,且已了一些逆转.因此,在增量更新中,Johan最终可能会做出不必要的更改.
上个版本使dub fetch项目可相关,这样可取项目的所有依赖.然后使用-cache=local,来在你的项目中存储它们.
他们想要更多改进.
原文地址：https://blog.csdn.net/fqbqrr/article/details/140397033
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！