本文主要是介绍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
来说,这似乎也很好.沃尔特说就要这样.
这篇关于2406,D2024年二月会议的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!