2406,D2024年二月会议
赞
踩
参会者
以下人员(略)出席了会议.
前面
我告诉大家,社区对话系列复兴的第一个视频相当顺利.马丁做得很好.因为拉兹万和我已讨论过他的参与,我问他是否愿意做下个.他接受了.另一个
第1项目:数组文本的d运行时勾挂实现
Razvan总结了TeodorDutu在他的,即用模板替换d运行时勾挂的项目中遇见的一个问题.
即,因为编译器,即他用来降级的方法,在式语义时处理它,并在式节点中存储降级,这对ArrayLiteralExp是不可能的.
Teodor的论坛帖子.
其他勾挂也有类似问题.Razvan和Teodor讨论的方法是,在数组或列表中,保存需要降级的式的指针,然后在语义后降级.
这也可摆脱,在AST节点中为了存储降级的字段.
马丁指出,伊恩在过去降级的讨论中,提出了该方法.使用AST节点中的字段的主要原因是,语义后降级会导致CTFE引擎出现性能问题.
使用字段更简单.因此保留带降级字段的AST节点.
拉兹万说,他的提议不会影响ctfe.Iain提出的方法的主要问题是,在AST上它需要另一个趟.但是他和特奥多尔的提议可避免它,因为在全局范围内,存储指向需要降级的式的指针.
马丁说,这是优化问题.必须看看缓存是否会得到回报,或是否仍会受到性能影响.
然后,他回顾了Iain提案的另一个问题,即有时,在输出AST节点时,你不想降级,如,在生成C和C++头文件或DI文件时.
他不知道该如何继续,但似乎已达到了降级字段的极限.
Razvan说,确实有解决方法,但会使代码更丑.新方法更加干净.
Walter指出,他最近遇见了一个问题,即d运行时调用已删除,并按语义趟中的模板替换的数组构造器.
然后,内联器试生成更多需要从数组构造器转换为模板的情况,而后端因为无法再调用数组构造器,而失败.
因此,他给内联器添加了,避免导致生成另一个运行时勾挂的内联代码的代码.
因此,在降级运行时勾挂时,重构很好.现在,它是临时的,且会引起问题.
Razvan说,在语义趟中降级新的勾挂,而在生成IR中的语义趟后降级旧的勾挂.因为一直在渐进实现新勾挂,因此在代码中,目前同时有旧勾挂和新勾挂.
当他们完成时,想把它们都放在一个地方,而Razvan认为,最好在语义趟后这样做.
Walter说,另一个问题是CTFE会面临一个降级的数组构造器,因此在CTFE中,他必须输入代码来展开构造器.因此,何时降级是个问题.
也许只能按单独趟处理它们.他问还有哪些新的降级.
Razvan说,只是选了些IR生成器正在用的,并压到式语义上.目标是完成工作.这对GDC和LDC来说是件好事,因为他们不再需要支持代码.
一切都会在前端处理.沃尔特问还剩下多少,拉兹万说不确定.特奥多尔曾说过他会在夏天完成,所以已实现大部分.
Walter说好的,并建议最好是在E2IR前,但在完成语义和内联后.拉兹万说,他也一样.
如果允许,他会和特奥多尔讨论实现它.沃尔特说,他们可继续.
马丁说,应该在内联前降级,因为内联的成本可能很明显.勾挂可能会很小.因此,如果其中至少把有一部分转发到另一个非模板函数,则可在运行时中预先编译这些函数.
Razvan问他是否建议在后端安装内联器,或是否可在前端内联器介入前降级.
马丁说他以前不知道怎么做的.因此,如果它只是前端内联,则这只是个DMD问题,因为LDC和GDC都不用它.他对此没有意见.
沃尔特说,他已实现了另一个,在中间代码上操作的内联器.它不完整,因此仍有前端内联.最好,它会消失.
应该与GDC和LDC那样,在中间代码级完成它.把它放在前端,是他的设计错误.他还没有完成中间的内联,但它就在那里运行了.
他说,它目前问题是,它只适合单个式函数.对带多个语句的函数不管用,因此它不够好.是他的原因.他说,在删除前端内联下工作是公平的.
他想完成它,否则允许从前端删除大量代码,这是错误的做事方式.
Razvan说这是对的,而且这样更易实现勾挂.沃尔特说,新的内联器,是按语义和编码间的单独趟完成的,因此正好符合Razvan的降级位置的想法.
Steve指出,编译代码不需要内联器.这只是个额外优化.因为使用D,并关心性能的人,都会使用LDC或GDC而不是DMD,因此即使还未完成新的内联器,也可继续摆脱前端内联.
沃尔特说这很好.他还表示,他需要研究实现多语句声明需要的工作量.
项目2:DMD按库
Razvan说,作为SAOC的一部分,一名学生正在努力整合按库DMD到dfmt中.他几乎完成了它.但是,有一个问题,即DMD丢弃了非Ddoc注解.
使用dfmt时,你不想丢弃评论.
还有另一个项目,在DScanner中使用按库DMD.在那里,他们搞逐步替换libdparse.去年夏天,DScanner上游代码搞了一次重大重构.
这使得重定基变成一段噩梦.但是他们完成了它,然后想使用最新版本的按库DMD.就在那时,Razvan注意到,在编译器代码基中都没有测试ASTBase.
因此,删除了一些字段,移动了一些函数,所以现在因此出现了各种各样的错误.
他提出了一个拉请,要求向测试包添加一个测试,以确保解析器使用ASTBase编译.所以现在很好.但所有这一切都让他思考未来.
dfmt和DScanner使用按库DMD.这已完成.但现在必须担心不会破坏这些工具.所以他一直在想,编译器提供的接口的策略是什么.
现在,没有用语义例程的项目.他们只是使用了文件解析器和ASTBase.这很好,因为当一些代码,在编译器中移动时,很容易修复这些代码.
但是,一旦人们开始在DMD中,使用经常修改的语义例程和代码,则最终会遇见该接口问题.
他引用了DScanner中的一个,因为DMD中删除了AST式节点中的布尔字段而出现的具体示例.
如,该字段指示,在不带括号的if式中,何时使用逻辑符号,以便DScanner可对此发出警告.但现在,随着它的消失,他们不得不重新引用代码以查看括号是否平衡.
他预测,该类事情最后会变成一个问题.如果要从AST节点中删除字段,也许可用按库DMD的版本,来在DMD外保留它们.
不过,这不好,因为最终会得到专门为DMD库构建的AST节点.
沃尔特说,他不知道为什么移除了父字段,并问是否是他.拉兹万承认了,并认为沃尔特过去用来节省空间.
沃尔特说有几种方法可完成.为了节省空间,父字段可能应该是一个位标志,而不是一个单独的布尔值.但这并不能解决一般问题.
他说,为此,最好让AST节点有个哈希表的指针.哈希表存储可能叫"可选"字段的内容.这或是个更普遍的解决办法.
这样,按库DMD可添加自己的字段到哈希表中,并且不会干扰编译器工作.
他说那只是个想法.或只是求助于继承类,但是其他继承类呢?会导致AST树的分支,而Razvan已解决了它.
拉兹万说,这不仅是字段.删除字段时,你或删除与它关联的一切逻辑.然后,在DMD即库中重现它更加复杂.
他说现在这不是个大问题,但要考虑它.人们还没有经常使用DMD即库,但是一旦开始依赖它,则最终会遇见从编译器更改中,破坏工具的问题.
他回忆说,Martin曾经建议将按库DMD按DMD的一个分支维护,但Razvan认为这将更难维护.
沃尔特说,不行.已有三个版本的AST了,2个D版本和C++版本,这已够糟糕了.他很想摆脱C++版本,但他知道马丁和伊恩使用它.
罗伯特说,或许把所有这些工具都折叠到DMD中,然后DMD会变成一个编译器守护程序,你向它发送作业,它编译它们,并尽量缓存.
而LSP服务器现在是列表的首位,这是迈向目标的步骤之一.
Razvan说,他设想的方式是,仍拥有设计接近现在设计的发布编译器.然后,还拥有个DMD即库和一个用来实现LSP逻辑的单独项目.
他不知道是否应该整合LSP逻辑到DMD中,且认为之前没有讨论它.
罗伯特说,如果用户除了安装DMD外还必须做其他事情,来取LSP服务器,dmft和DScanner,则就失败了.
这一切都必须按一个版本绑定在一起,无论它是否内置在编译器二进制文件中.他坚信,最终目标应该是,使用D作为工具的人,如果安装了DMD,只要他们打开编辑器,就应该在那里拥有LSP.
这是怎么完成的并不重要.
Walter同意dfmt,DScanner和LSP服务器都应该是一个匹配的集合,且应该包含在发布中.他最近不得不使用Dustmite,并认为他必须从配音中取它并重构它等等,然后他发现它已是编译器的一部分.
这真是大不相同.它应该是发布的一部分.
如果想走版本(按库DMD)路线,他可接受的是一个,如一个void*指针的泛型字段,可对额外字段的按关联数组动态使用,但就这样.
Razvan说,关键是如果想添加字段或函数,修改接口是可以的,但如果要删除它们,可把它们放在版本(按库DMD)中.
但他同意,不应为每个使用DMD即库的人打开大门,来添加新字段等.
沃尔特说,他不知道GDC和LDC使用了哪些函数.他要求使用他们的所有函数按extern(C++)标记,以便可区分它们.
拉兹万说,现在就这样.但是GDC或LDC并没有使用一些按extern(C++)标记的函数.沃尔特说应该删除这些,但他不知道是哪些.
Iain说,他非常确定每个成员函数,都已有一个显式的extern(D)或extern(C++).他说几乎每周他都会收到更改日志项,并最终在前端接口,更新不少于三个文件.
Iain认为,在定义函数的地方,不能只是内联C++名字空间,但也许Razvan可使所有移动的函数为extern(D).
然后有一个如dmd.cppapi的叶模块,包含移动函数的extern(C++)转发函数.然后,外部(C++)的所有内容都集中在一个地方,而不是到处分散.
沃尔特说这似乎很好.Razvan说,即使对按库DMD来说,这似乎也很好.沃尔特说就要这样.
