DLF2023年9月月度會(huì)議摘要

Robert

Robert,在DConf上做了一些初步的JSON5工作.他還更新了Bugzilla到GitHub的遷移腳本.他使用了"隱藏"API,現(xiàn)在腳本要快得多.
除此外,他在DScanner上做了一些小事,并等待JanJurzitza(Webfreak)合并它們.他指出,沃爾特曾要求他寫一篇演講,他準(zhǔn)備寫DScanner相關(guān)的博客文章.

亞當(dāng)

無法訪問的代碼
亞當(dāng)首先提出了"無法訪問語(yǔ)句"的警告.他說這真很煩人,應(yīng)該消除它.誤報(bào)破壞了它提供的價(jià)值,且它并不能減少錯(cuò)誤.有一個(gè)PR可版本化它.
蒂蒙贊成擺脫它,因?yàn)樗X得它最煩人.
Steve同意該功能幾乎沒用.
默認(rèn),Dub警告為錯(cuò)誤.他說,寧愿看到編譯器刪除無法訪問的代碼,也不愿忍受發(fā)出警告.

馬丁說,同意.對(duì)那些想要它的人來說,該功能應(yīng)該包含在可配置的linter中.它幫助了他幾次,但它在很多場(chǎng)合都阻礙了他.

Walter問,在模板擴(kuò)展中,禁止警告行不行?亞當(dāng)說可以,但舉了個(gè)二分法示例,此時(shí),
在assert(0)中,現(xiàn)在它不再編譯.

Walter同意這很煩人,亞當(dāng)說,要看看性價(jià)比.
即使收益不為零,成本也是巨大的.
沃爾特同意了,并說如果移除它并放在到檢查器(linter)中,問題不大.

丹尼斯,指出,編輯器最好可利用這些信息.如,code-d按灰色顯示未使用的參數(shù),因此盡管未用,也不會(huì)造成干擾.
他建議禁止dmd中的簽入,但保留它的代碼,以便DMD庫(kù)的客戶可用它.沃爾特說這很好.

更新:Adam此后修改了他的PR,以便禁止檢查但未刪除,且已合并PR.

DLF角色

接著,亞當(dāng)問誰(shuí)負(fù)責(zé)標(biāo)準(zhǔn)庫(kù),并說曾經(jīng)是安德烈.我回答說是atila.
Dennis已在YouTube頻道上開始了貢獻(xiàn)者教程系列,并計(jì)劃繼續(xù)下去.

史蒂夫

Steve報(bào)告說,他一直試讓他的移植Raylib中使用ImportC.他發(fā)現(xiàn)ImportC已走了很長(zhǎng)一段路.除了一些鏈接器錯(cuò)誤,已到了幾乎可工作的地步.

他一直在與Martin合作解決這些問題,并想在下個(gè)LDC版本中修復(fù)它們.在下個(gè)版本的LDC中,他可能會(huì)有一個(gè)內(nèi)部啟用了ImportC部件的Raylib移植.
他覺得這很令人興奮.如果ImportC可達(dá)到可從C導(dǎo)入要求內(nèi)容的地步,則會(huì)避免創(chuàng)建移植和綁定的許多麻煩.

接著,他說他開始了他的下一個(gè)D編程課.但在窗口上,還需要更多改進(jìn),以啟動(dòng)和運(yùn)行一切.

Timon

Timon說,在DConf上,他本來打算修復(fù)一些bug,但他嘗試了其他事情:他在foreach循環(huán)中,解包元組.

然后,他做了個(gè)演示.然后他展示了他發(fā)現(xiàn)的一個(gè)問題.有時(shí)候,Phobos元組的實(shí)現(xiàn)方式,對(duì)結(jié)構(gòu)實(shí)例,會(huì)導(dǎo)致多次后復(fù)制和析構(gòu)器調(diào)用.

解包元組時(shí),情況更糟.最好,可用移動(dòng)替換所有這些調(diào)用.這有點(diǎn)煩人,這是語(yǔ)言的局限性.

Walter感謝他在元組上的工作.
Dennis說,移動(dòng)語(yǔ)義和復(fù)制構(gòu)造器難以理解.很難理解DIP.阿蒂拉說,這被擱置了,要完成它,現(xiàn)在肯定有不應(yīng)有的副本.

我建議把Walter的"復(fù)制,移動(dòng)和轉(zhuǎn)發(fā)DIP視為一個(gè)穩(wěn)定功能,而不是增強(qiáng)功能.必須把它弄進(jìn)去.阿蒂拉同意了,因?yàn)?code>不應(yīng)有副本.
雖然,聲稱有移動(dòng),但有時(shí)它們不管用.

蒂蒙同意了,并提出,目前沒有除運(yùn)行時(shí)系統(tǒng)外,合法方法來釋放不變值.
蒂蒙重復(fù)了"是沒有合法方式".如果函數(shù)只是釋放不變值,因?yàn)樗祷?code>void,編譯器可省略它.

因?yàn)樗?code>純(pure)的.需要說明要消耗每個(gè)值.默認(rèn),與析構(gòu)器一起使用,但應(yīng)該可有函數(shù)說,“我現(xiàn)在正在使用該值”,然后在調(diào)用函數(shù)后它就消失了.

有core.lifetime.move,但它并沒有考慮移除它.它只是默認(rèn)初化它,然后你再次得到該純析構(gòu)器調(diào)用.
Martin說Timon的演示很酷,并懷疑他的生命期問題來自膠水層,如果可能,它會(huì)直接在最終的局部變量中放置調(diào)用函數(shù)的結(jié)果.

因?yàn)橐恍┤?code>結(jié)構(gòu)的構(gòu)造器等特例,它需要在膠水層中處理.這太丑陋了.如果保持現(xiàn)在接口,則需要在每個(gè)膠水層中重新實(shí)現(xiàn)元組支持,而不僅是dmd,以使事情正常工作.

Martin繼續(xù)說:正如Timon所提到的,運(yùn)行時(shí)存在語(yǔ)言限制.基本構(gòu)建塊就在那里,但Timon的析構(gòu)器示例就是限制之一.

因此Martin一直要求把移動(dòng)和轉(zhuǎn)發(fā)搞成內(nèi)置,而不是當(dāng)前庫(kù)方法.如果內(nèi)置它們,也可擺脫一些模板膨脹.

當(dāng)然,也不想要那些額外的后復(fù)制和析構(gòu)器調(diào)用,但如果負(fù)載非常大,即使是移動(dòng)的析構(gòu)成本也可能非常高.如,4kb移動(dòng)不是免費(fèi)的.

最好,直接部署.但是很可能要更改AST才行.

Timon感謝Martin的見解.然后,Martin詳細(xì)介紹了它是如何入侵到語(yǔ)言中,及移動(dòng)和原位放置的現(xiàn)在的工作原理.

他還說,在DRuntime中發(fā)現(xiàn)了多個(gè)實(shí)現(xiàn),并試簡(jiǎn)化一切以使用core.lifetime.move,但最好,move和emplace應(yīng)該是內(nèi)置的,而不是庫(kù)方法.

沃爾特說,很久以前,他就寫了轉(zhuǎn)發(fā)和移動(dòng)的DIP,他需要重新熟悉它.他指出,在實(shí)現(xiàn)@live中,他對(duì)移動(dòng)語(yǔ)義很感興趣,因此把移動(dòng)語(yǔ)義構(gòu)建到語(yǔ)言中的提議,都可能會(huì)對(duì)@live產(chǎn)生更好的影響.

所有權(quán)/借用系統(tǒng)基于移動(dòng)而不是復(fù)制.不久前,他把DIP交給了Max(當(dāng)時(shí)決定Walter和atila不應(yīng)再評(píng)判他們自己的DIP,事后看來這是一個(gè)錯(cuò)誤),但它從未完成.

沃爾特說,目前有很多優(yōu)先事項(xiàng).阿蒂拉一直在推動(dòng)他改變shared的語(yǔ)義,他已同意了.

這也阻礙了很多人.然后是ImportC問題(耗時(shí)工作).所以他同意應(yīng)該暫時(shí)把移動(dòng)放一放.

馬蒂亞斯

Mathias提出了-preview=in.在過去一次會(huì)議上,Mathias同意改變dmd的行為,使其總是按引用(ref)傳遞(Walter認(rèn)為有時(shí)按值傳遞,有時(shí)按ref傳遞是不一致).
他報(bào)告說,與DConf的Ahrefs討論后.他們對(duì)D的C++整合非常感興趣.遇見了個(gè)問題,因?yàn)橛行┫胍?code>按引用傳遞的類,但是當(dāng)有接受類為參數(shù)的函數(shù)時(shí),會(huì)按指針管理它.

他們已討論了按引用傳遞它的方法.Mathias想要實(shí)現(xiàn)概念驗(yàn)證,且已與Walter討論了.

馬丁

馬丁說,他一直在為LDC的D2.105而努力.目前,它進(jìn)展得相當(dāng)順利.最新編譯器版本,終于可針對(duì)Symmetry代碼基測(cè)試.

已修復(fù)一些2.103和2.104回歸.為此感謝拉茲萬(wàn).一切正常.他想可針對(duì)2.106.0版本盡早測(cè)試Symmetry的代碼基.

最后,他告訴Steven,在LDC1.35版本,部分修復(fù)他報(bào)告的ImportC問題.

Dennis

是測(cè)試問題.

拉茲萬(wàn)

模板問題

Razvan從Martin提到已修復(fù)回歸開始.它們是由Walter的PR引起的,目的是在推導(dǎo)環(huán)境時(shí),阻止編譯器發(fā)出實(shí)例化運(yùn)行時(shí)勾掛模板的降級(jí).

他說,一般,找到新的數(shù)組式時(shí),你會(huì)立即降級(jí)它到newarray模板中,然后實(shí)例化模板,并分析它,并在某個(gè)字段中存儲(chǔ)它.

但是,如果該環(huán)境是CTFE,則一般,不需要這樣.你總要解釋該式.但有時(shí),即使在CTFE環(huán)境中,仍需要降級(jí).

因此,如果不降級(jí),這時(shí)你最終會(huì)遇見實(shí)例化錯(cuò)誤.
他說,這里的方法是總是實(shí)例化模板,并按降級(jí)保存,但這樣,就不必總是為它發(fā)出代碼.該方法也有問題.前端現(xiàn)在是,在推導(dǎo)環(huán)境中,有實(shí)例化模板時(shí),它會(huì)按不需要生成代碼,來標(biāo)記模板實(shí)例.

但是,如果實(shí)例實(shí)例化其他模板,則不再按推導(dǎo)模板標(biāo)記這些模板.如果未生成根模板,卻生成了子實(shí)例,這也會(huì)導(dǎo)致問題.

如,他引用了其中一個(gè)回歸:給定一個(gè)實(shí)例化map的__ctfe塊,按別名參數(shù)把λ傳遞給它,則因?yàn)樗窃?code>CTFE環(huán)境中,就不會(huì)把代碼降級(jí)到勾掛上.

但隨后,把λ傳遞給映射實(shí)例化的其他模板,則在這些環(huán)境中分析它時(shí),會(huì)導(dǎo)致ICE.

需要查看根實(shí)例化是什么,并傳播不需要codegen它觸發(fā)的子實(shí)例.

馬丁說,拉茲萬(wàn)所描述的,一般都應(yīng)有效.但這很復(fù)雜.然后,他詳細(xì)介紹了推導(dǎo)實(shí)例觸發(fā)的模板實(shí)例化.

當(dāng)前實(shí)現(xiàn)有一些問題,也有一些解決方法,但回歸與此無關(guān).他說,有時(shí)候,依靠新的模板降級(jí)來自行生成錯(cuò)誤,以抓一些錯(cuò)誤情況,對(duì)這些失敗很不錯(cuò).

在CTFE中,只需檢查是否有問題,會(huì)短路它,又因?yàn)橐僭O(shè)它總是有效的,會(huì)跳過降級(jí).這不會(huì)切掉它.這是主要問題.實(shí)例化降級(jí)模板可能失敗時(shí),需要刪除這些檢查.

這就是已修復(fù)問題,現(xiàn)在運(yùn)行良好.

馬丁說,也許最好,在前端去掉降級(jí).Walter建議,也許應(yīng)該按舊方式在膠水代碼中降級(jí).Razvan說,因?yàn)楝F(xiàn)在運(yùn)行時(shí)使用模板,這樣做就是放棄了現(xiàn)在這些問題.

還出現(xiàn)了不經(jīng)常遇見的其他模板問題,但現(xiàn)在在運(yùn)行時(shí)使用了模板,它們更加明顯.

他說,另一個(gè)問題是屬性.這些降級(jí)是從各種屬性環(huán)境中完成的.目前,在實(shí)例化模板,如果有循環(huán)依賴關(guān)系,則推導(dǎo)不管用.

編譯器只是假設(shè)它們是@system的,不純的,非@nogc的,等等.這里,不是前端模板降級(jí)問題,而是有些需要修復(fù)的模板發(fā)射或實(shí)例化錯(cuò)誤.
馬丁同意了.

關(guān)于屬性推導(dǎo),Timon說,也許這是計(jì)算最大而不是最小不動(dòng)點(diǎn)問題.編譯器應(yīng)總是推導(dǎo)屬性,但目前,它不是盡量推導(dǎo)它們.

這不對(duì).但是,如果不自省,要做好就有點(diǎn)麻煩了.
Martin說,過去,Symmetry的代碼基就曾受到停止推導(dǎo)屬性的打擊.編譯器有時(shí)會(huì)跳過它.比如,當(dāng)在特定實(shí)例中,需要它的成員函數(shù)之一,且還沒有語(yǔ)義分析聚集時(shí).

完全跳過了推導(dǎo).這很麻煩.

Razvan說,不應(yīng)codegen的實(shí)例,而codegen時(shí),他正在研究該問題.他想找出問題所在.

DMD庫(kù)中的AST節(jié)點(diǎn)

自DConf以來,Razvan一直在考慮DMD庫(kù)如何提供任意覆蓋各種AST類型.

他給了該AST實(shí)現(xiàn)使用的表達(dá)式類層次的示例:

module expression;
import std.stdio;
class Expression {}
class BinExp : Expression
{void fun(){writeln("expression.fun");BinExp p = new BinExp();Expression e = new Expression();}
}
class BinAssignExp : BinExp
{}
class AddAssignExp : BinAssignExp
{override void fun(){writeln("AddAssignExp");}
}
class MulAssignExp : BinAssignExp
{}

然后在ast_family.d中,默認(rèn)ASTCodegen如下:

struct ASTCodegen
{public import expression;
}

要?jiǎng)?chuàng)建自定義AST并覆蓋如BinExp等的默認(rèn),需要執(zhí)行如下操作:

struct MyAST
{import expression;import std.stdio;alias Expression = expression.Expression;class MyBinExp : expression.BinExp{override void fun(){writeln("MyBinExp.fun");}}alias BinExp = MyBinExp;alias BinAssignExp = ??
}

問題是,為了使用你的自定義實(shí)現(xiàn),必須聲明從BinExp繼承的所有AST節(jié)點(diǎn).這不可行.
不僅要可指定要覆蓋指定節(jié)點(diǎn),還要指定其他節(jié)點(diǎn)要用它.
首先,考慮了模板化AST節(jié)點(diǎn),并從模板化版本繼承,但要大量修改編譯器.然后想出了使用mixin的方法.只需插件(mixin)入期望AST節(jié)點(diǎn)的代碼即可.
使用該方法,AST節(jié)點(diǎn)現(xiàn)在是mixin模板:

module expression_mixins;
import std.stdio;
mixin template Epression_code()
{class Expression {}
}
mixin template BinExp_code()
{class BinExp : Expression{void fun(){writeln("expression.fun");BinExp p = new BinExp();Expression e = new Expression();}}
}
mixin template BinAssignExp_code()
{class BinAssignExp : BinExp{}
}
mixin template AddAssignExp_code()
{class AddAssignExp : BinAssignExp{override void fun(){writeln("AddAssignExp");}}
}//插件.
mixin template MulAssignExp_code()
{class MulAssignExp : BinAssignExp{}
}

然后表達(dá)式模塊變?yōu)?

module expression;
import expression_mixins;
import std.stdio;
mixin Expression_code();
mixin BinExp_code();
mixin BinAssignExp_code();
mixin AddAssignExp_code();
mixin MulAssignExp_code();
//插件.

在ast_family中,ASTCodegen不變,但現(xiàn)在,可如下自定義AST:

struct MyAst
{import expression_mixins;import std.stdio;mixin Expression_code();mixin BinExp_code() t;class MyBinExp : t.BinExp{override void fun(){writeln("MyBinExp.fun");}}alias BinExp = MyBinExp;mixin BinAssignExp_code();mixin AddAssignExp_code();mixin MulAssignExp_code();
}

可在前端庫(kù)中,自動(dòng)生成樣板.重點(diǎn)是,現(xiàn)在可無需重新聲明所有內(nèi)容,在層次中,用自定義實(shí)現(xiàn)替換任意默認(rèn)節(jié)點(diǎn).

此例中,從BinExp繼承的所有內(nèi)容,現(xiàn)在都從MyBinExp中繼承.這管用.這是可行的.

基本上是個(gè)可插件的AST,相關(guān)丑陋是值得的.

阿蒂拉說他喜歡它.
Razvan指出,問題是語(yǔ)義例程訪問器將不再起作用.但很酷的是,也可把它們放在mixin中.用自定義語(yǔ)法樹節(jié)點(diǎn),你繼承的,并覆蓋期望訪問節(jié)點(diǎn),混合這些,得到了期望的所有功能.

Timon說,dmd在試構(gòu)建自己時(shí)會(huì)有問題.
如"未定義的標(biāo)識(shí)串",一般前向引用錯(cuò)誤或ICE等.
Razvan說,他遇見了未定義標(biāo)識(shí)問題,但可在問題點(diǎn)插入別名來解決.這些都是需要修復(fù)的編譯器錯(cuò)誤.
Timon同意了.

Dennis指出,bootstrap編譯器不會(huì)修復(fù)程序.Martin說你要提高bootstrap編譯器版本.然后他說,如果,只有單個(gè)AST,它就可正常工作.
但是,需要多個(gè)AST的工具都需要完全不同的類層次.即使只對(duì)小小的BinExp感興趣,也可能影響其中的幾十個(gè)類,但不會(huì)影響整個(gè)數(shù)百個(gè)類.

你想在AST之間共享一個(gè)被覆蓋的類.

拉茲萬(wàn)說,這是可以做到的.在AST族,外部聲明該類,然后在族內(nèi)使用別名.

Steve說,問題是,在編譯器中查看實(shí)現(xiàn)時(shí),你查看BinExpression,并看到AddAssignExpression繼承自它,它有可能從與上面完全不同的東西繼承.

很難跟蹤這一點(diǎn).特別是如果有個(gè)替代的AST,如,對(duì)DMD庫(kù).跟蹤事物去向及繼承方式會(huì)令人困惑.

Razvan說,如果你正在研究編譯器,不應(yīng)有混淆.在mixin中看到的是實(shí)現(xiàn).不會(huì)再有覆蓋.對(duì)編譯器庫(kù)的用戶來說,有點(diǎn)令人困惑,但你仍必須選擇要覆蓋的AST節(jié)點(diǎn).

他預(yù)計(jì)接口將比所有這些樣板,所有多個(gè)插件文件要簡(jiǎn)單得多.還可以是自動(dòng)化的.然后,只需要指定要覆蓋的類即可.是的,有點(diǎn)令人困惑,但DMD現(xiàn)在的組織方式,他不知道你如何保留代碼的當(dāng)前狀態(tài),并繼續(xù)前進(jìn).

Mathias認(rèn)為目前,這似乎是唯一方法.

沃爾特說還有另一個(gè)方法.與其在AST節(jié)點(diǎn)之外,不如在節(jié)點(diǎn)里面,放置mixin.讓AST節(jié)點(diǎn)插件至用戶定義的模板中.這樣,不用折騰,就可添加功能.

拉茲萬(wàn)說他也考慮過,但仍需要定義所有定義.沃爾特說,在主編譯器中,只需留空.Razvan同意,但編譯器庫(kù)用戶仍必須定義所有AST節(jié)點(diǎn),然后手動(dòng)插件感興趣節(jié)點(diǎn).

對(duì)史蒂夫評(píng)論,這將更丑陋.因?yàn)楝F(xiàn)在,查看表達(dá)式實(shí)現(xiàn),第一反應(yīng)是它很丑陋.但它封裝得非常好.你有整個(gè)類,只需插件進(jìn)你的AST族.

他說,這很有效.好處是可逐步實(shí)現(xiàn)它.可逐步取每個(gè)AST節(jié)點(diǎn),并把它放入mixin中,然后插入進(jìn)AST代碼中,并查看它是否有效.

如果因?yàn)?code>編譯器錯(cuò)誤而遇見問題,則很容易跟蹤它.是的,這需要大量更改編譯器,但現(xiàn)在,如果不修改所有AST節(jié)點(diǎn),就不可能覆蓋它們.

沃爾特說,他不明白為什么把插件放在類里而不是放在類外,就不會(huì)完成,只是減小侵入性.atila說你必須定義所有子類.

仍需要手寫它們.沃爾特不認(rèn)為這是真的.Razvan說,你定義你的AST時(shí),仍要寫Expression類,然后插件內(nèi)容.

沃爾特說,你重定義了所有插件內(nèi)容.史蒂夫說,你可把所有混進(jìn)去的傳遞給類.然后用它來插件代碼.

Walter說,在你擁有的每個(gè)語(yǔ)義節(jié)點(diǎn)中,你列舉繼承等等,然后插件到特征模板中.編譯器的函數(shù)模板與用戶庫(kù)的函數(shù)模板不同.

然后,如果想修改一個(gè)AST節(jié)點(diǎn),只需修改該AST節(jié)點(diǎn)的mixin.這就是你所要做的.

Razvan問,想添加另一個(gè)字段或函數(shù)時(shí),會(huì)怎樣.按參數(shù)傳遞它們?atila說不行,因?yàn)?code>必須為此傳遞與API中的AST節(jié)點(diǎn)一樣多的mixin,或只傳遞一個(gè),然后就會(huì)插件到每個(gè)AST節(jié)點(diǎn)中.

沃爾特提出了另一個(gè)方法.已從AST中刪除了語(yǔ)義階段,現(xiàn)在它們是單獨(dú)完成的.可更進(jìn)一步,刪除更多覆蓋函數(shù)等等.

讓AST樹像ASTBase中的樹,即它只是層次.然后用戶可修改它.這只是個(gè)想法.只需刪除相關(guān)編譯器的所有AST內(nèi)容,這樣它就更像是個(gè)用戶無需修改即可使用的空的AST.

拉茲萬(wàn)說,四年前就有該方法,但當(dāng)時(shí),才開始重構(gòu).Razvan認(rèn)為這是正交的,因?yàn)?code>除非還與mixin方法結(jié)合使用,否則仍無法向AST添加新字段.

Walter同意它不會(huì)添加新字段.阿蒂拉問是否需要.難道不是你在寫自己的訪問者嗎?為什么需要在那里修改AST.

Razvan:因?yàn)槟壳?code>語(yǔ)義階段在使用AST.解析器需要特定AST結(jié)構(gòu).因此,如果想添加一些字段來存儲(chǔ)一些信息以在語(yǔ)義分析時(shí)使用,則…

Timon說,每個(gè)類都有插件功能是有效的,因?yàn)?你可根據(jù)該類型來靜如(static if),查看你在哪個(gè)節(jié)點(diǎn)上,可把你的代碼準(zhǔn)確注入到正確節(jié)點(diǎn)中.
Dennis說,他還不確定DMD庫(kù)的哪個(gè)應(yīng)用真正需要覆蓋類.除了靜態(tài)增強(qiáng)類,每個(gè)AST節(jié)點(diǎn)都有個(gè)標(biāo)識(shí),或只是額外的庫(kù)空針,如何?則無需繁重模板和插件機(jī)制,庫(kù)可動(dòng)態(tài)轉(zhuǎn)換和讀取該字段.

Razvan引用了未用導(dǎo)入工具中的一例.在那里,當(dāng)編譯器解析名字時(shí),在符號(hào)類的域中,有個(gè)搜索方法.
只要覆蓋該方法,再存儲(chǔ)一些信息等.

在此,談話轉(zhuǎn)向了dmd中虛/終函數(shù)的使用,為了dmd庫(kù),要如何更改,及更改API對(duì)用戶代碼破壞的可能性.
Razvan指出,LF最終可能會(huì)由Weka使用的個(gè)人項(xiàng)目,希望可修改AST節(jié)點(diǎn).現(xiàn)在,因?yàn)槲刺峁?code>適當(dāng)接口,他必須跳過很多障礙.

Razvan表示,他愿意為此努力,并向dmd提交一些PR,看看是否可行,或是否只是遇見了障礙.他問沃爾特是否贊成探索它,或認(rèn)為它太丑了.

阿蒂拉重復(fù)了一遍,他喜歡它.Walter問其他編譯器是如何做到的.這觸發(fā)了一些關(guān)于clang和Java編譯器的討論.

Martin表示,現(xiàn)在不太擔(dān)心會(huì)破壞編譯器的API.現(xiàn)在只是用它作dmd庫(kù)的完整起點(diǎn).因此,不必?fù)?dān)心API的巨大變化.

一旦有了依賴它的穩(wěn)定工具,那不行了.LLVM有重大API更改.甚至?xí)?code>三個(gè)不同棄用步驟的版本.
D現(xiàn)在不存在.

Walter擔(dān)心這是對(duì)編譯器內(nèi)部的痛苦更改,且不確定這是否值得.編譯器中有很多AST節(jié)點(diǎn),現(xiàn)在要全部覆蓋它們.

Razvan說,對(duì)他來說,與模板化解析器或移出語(yǔ)義階段時(shí)一樣.Walter說,模板化解析器有點(diǎn)失敗.Razvan說,這是因?yàn)闆]有跟進(jìn)語(yǔ)義.

模板化了解析器,但已存在libdparse,所以未提供新東西.有一堆庫(kù)在不同規(guī)模上,做dmd已在做的事情.

沃爾特說他有點(diǎn)喜歡void*方法,這樣,編譯器可毫不知情地添加勾掛.

Timon問,為什么不直接模板化分析AST族,并讓庫(kù)擁有自己的可勾掛AST.這就不會(huì)干擾標(biāo)準(zhǔn)編譯編譯器.也不會(huì)編輯現(xiàn)有的AST節(jié)點(diǎn).

Walter說,如果編譯器是適當(dāng)模塊化的,就不必模板化.如果正確封裝內(nèi)容,只需為不同行為導(dǎo)入不同模塊即可.

可考慮,看看是否可減少AST節(jié)點(diǎn)的導(dǎo)入次數(shù).試使它們更具插件性.因此,與其使用模板等,不如導(dǎo)入帶自己功能的不同模塊.

有很多方法可完成.

Timon問,如何告訴現(xiàn)有模塊,請(qǐng)導(dǎo)入我的模塊而不是現(xiàn)有模塊.這仍需要模板化.Walter說,你可把你的模塊放在不同目錄中,并用-I開關(guān)給編譯器指出來.

然后就有了不同的實(shí)現(xiàn).

拉茲萬(wàn)說,那不再是庫(kù)了.你必須替換現(xiàn)有文件為你的文件.這不能解決問題.
Walter:所以即它是否應(yīng)該是已編譯的DMD庫(kù)或源碼DMD庫(kù).

拉茲萬(wàn)說是的.如果在修改文件,不妨只使用編譯器的一個(gè)分支.重點(diǎn)是:想與最新編譯器同步,且想擁有所有功能,只需插件要用功能即可.

Adam說,不修改文件,而是在構(gòu)建系統(tǒng)中,完全替換它們.但這是個(gè)痛苦.Razvan說,他想盡量重用現(xiàn)有代碼,因此,對(duì)指定文件,需要大量復(fù)制粘貼.

Walter說他理解Razvan說的,但如果更好封裝模塊,則與編譯器的其余部分同步的問題就少得多了.

如,他終于讓詞法解析器和解析器不再導(dǎo)入編譯器的其余部分.現(xiàn)在,你可插件不同的詞法解析器和不同的解析器,然后無需更改的使用編譯器的其余部分.

為什么不能用AST節(jié)點(diǎn)來完成?如果要更改語(yǔ)句節(jié)點(diǎn),只需導(dǎo)入不同的statement.d文件即可.

如果正確封裝它,則很容易把編譯器的statement.d替換為用戶版本.用戶可按合適方式調(diào)整.

Timon說,根本問題是,如何在許多不同類型的AST節(jié)點(diǎn)上重用語(yǔ)義.D文件接口不是好的接口.

也許可結(jié)合這兩者.

Walter說,已有用dmd的只是簡(jiǎn)單讀取目錄中的所有文件,并編譯在一起的單個(gè)命令,來替換build.d的討論.
這很有趣,并更容易從dmd源碼外構(gòu)建.他同意build.d的功能太復(fù)雜,它應(yīng)該只是編譯文件.

atila說,最好,人們只需在dub.json/sdl中加上dmd一個(gè)依賴項(xiàng),就可工作了.沃爾特同意了.

Martin說,這和之前在前端上放置linter類似.同樣,決定在編譯器中保留檢查無法訪問的代碼,以便工具可用它.

替換D文件不會(huì)削減它.需要介于兩者之間的東西.應(yīng)該有個(gè)DMD庫(kù)基的編譯器分支.因此,可在那里做mixin(插件),void*等,以便可用它.

這是有些輕微修改的半開放的前端接口.因此,可添加像void*等修改,或?yàn)樗?code>AST節(jié)點(diǎn)添加一些額外的狀態(tài),訪問者或需要的函數(shù),這些功能會(huì)有成本,且不想在前端中看到這些功能.

如,如果必須從一些性能關(guān)鍵方法中,刪除final屬性,以便可像用任意工具一樣使用前端,可在分支中這樣嘗試.并可把DMD庫(kù)作為GitHub上的一個(gè)單獨(dú)的項(xiàng)目.

可更新每個(gè)主要或次要版本,可在此基礎(chǔ)上構(gòu)建工具.這樣,就不必在編譯器自身中添加所有額外東西,從而變慢或變丑.

類似在LDC使用dmd作為前端.他們重寫了單倉(cāng)庫(kù)的歷史,排除了或移動(dòng)了一些文件到其他地方,以便可更方便地使用它們,并有些小調(diào)整,如增加些字段,替換些函數(shù)等.

跟上最新dmd變化還不錯(cuò).如果由社區(qū)團(tuán)隊(duì)處理,類似維護(hù)配音,這應(yīng)該很好.

沃爾特說,他很高興馬丁提出了該問題.他突然發(fā)現(xiàn)Martin和Iain已在使用dmd作為庫(kù),因此他們的經(jīng)驗(yàn)對(duì)如何更好完成它非常有用.

也許更好地支持它們,會(huì)更好地支持dmd庫(kù).他不知道是如何把它整合到LDC和GDC中的.
馬丁說,LDC和GDC顯然在修改D的某些部分,至少LDC是這樣,但只是很少.對(duì)其余接口,是與C++互操作.

Mathias說,這些不是特例,它們是DMD庫(kù)的用例.馬丁答應(yīng)了,但他沒有看到其中的關(guān)聯(lián).Mathias說,它們是人們需要DMD庫(kù)的各種功能的好示例.
目前,它們是黑客,因?yàn)樵?code>LDC版本塊中放置它們,并修改代碼.但是通過上游化它們,會(huì)把黑客變成適當(dāng)?shù)呐渲命c(diǎn),這就是重點(diǎn).

馬丁同意了.他的觀點(diǎn)是,不想丑化代碼,降低運(yùn)行時(shí)和編譯器源碼的可讀性.對(duì)檢查器或這些計(jì)劃的擴(kuò)展點(diǎn)也適合.

因此,可保持前端不變,并修改中間的DMD庫(kù),以簡(jiǎn)化一些勾掛,添加額外狀態(tài),如果要替換該功能,可能會(huì)替換整個(gè)AST.

他繼續(xù)重申,替換D文件建議,顯然不是想要的.與Razvan提出的未用導(dǎo)入示例一樣,期望重用大部分功能.

只需更換一個(gè)小的搜索功能.因此,DMD庫(kù)項(xiàng)目作為它自己的小項(xiàng)目開始侵改是相當(dāng)不錯(cuò)的.可見它是如何演變的.

還有extern(C++)接口,如何影響DMD庫(kù)的附帶討論.

Steven說,與新Phobos版本討論類似,即按完全不同的方式編譯重用相同代碼.

atila

atila說,在DConf之后,他問過Roy是否想為新的共享語(yǔ)義編寫規(guī)范,但還未收到回復(fù).但應(yīng)繼續(xù)下去.

他也一直在思考Robert關(guān)于安全代碼的建議,他做得越多,意義越大.不必等待版本,這樣,可解決DIP1000的所有問題,可能一舉解決.

整個(gè)問題是,因?yàn)橐?code>@safe,不得不到處添加域(scope).它應(yīng)只適合@trusted.
另一件事是:他一直在思考Timon的想法,即指針有個(gè)說明是否是隔離的編譯時(shí)枚舉.想用向量類型和一些分配器來搞個(gè)概念證明,看看怎么樣.

還會(huì)有些如何向語(yǔ)言添加隔離的信息.
還在思考該如何版本化.

丹尼斯認(rèn)為標(biāo)準(zhǔn)庫(kù)都會(huì)破壞.因此,DIP1000并不是一個(gè)重大變化.重大更改是修復(fù)了接受無效錯(cuò)誤,目前,已允許切片本地靜態(tài)數(shù)組.

羅伯特的提議,嚴(yán)格來說比DIP1000更有破壞性.

阿蒂拉說他理解這一點(diǎn),但,這段代碼顯然是錯(cuò)誤的.破壞了代碼.只是編譯器沒有告訴你.且DIP1000的問題是采納.問題是必須到處加域.

如果修復(fù)共享或域等會(huì)破壞很多代碼,難道不應(yīng)延遲到新版本,而不是默認(rèn)語(yǔ)言修復(fù)?Walter說DIP1000顯然必須在一個(gè)版本中.

阿蒂拉說:“好吧”.共享不難.代碼是完全錯(cuò)誤的,不會(huì)降級(jí)到原子來破壞.沃爾特同意了.

Timon問,該想法是否是在共享變量上原子操作.沃爾特說是的,針對(duì)CPU支持的原子操作.如果CPU不支持,則禁止.它因目標(biāo)而異.

Timon說是的,但原子操作不是唯一同步方法.阿蒂拉說這是真的,但問題是,總有人丟棄共享來選出.

如果打算直接共享,應(yīng)該把它傳遞給接受共享的函數(shù),或丟棄掉,并鎖定互斥鎖,或想要的其他東西.

Timon提到了Manu拒絕所有這些操作.阿蒂拉說這行不通.今年一直在努力修復(fù)它,但到處都是漏洞.
Timon問有什么問題.atila說有很多,如:synchronized(mutex)不能使用-preview=nosharedaccess編譯,因?yàn)槟阏?code>訪問互斥鎖.

運(yùn)行時(shí)不會(huì)用它構(gòu)建,Phobos也不會(huì).他一直在努力堵住漏洞,但發(fā)現(xiàn)最好不要這樣.相反,需要時(shí),只需降級(jí)到原子即可.

如果不編譯,就沒用.

Walter告訴Timon,問題是不能按參數(shù)傳遞共享值.如果創(chuàng)建了某項(xiàng)內(nèi)容的共享指針,則因?yàn)樗?code>共享的,無法操作它.

如果要訪問共享指針,則必須通過std.atomic的引用來傳遞它.但是,CPU上有原子加載指針類型和其他基本類型的指令.

為什么不利用這一點(diǎn),當(dāng)目標(biāo)CPU可直接支持共享操作時(shí),允許共享操作.
Timon說,似乎總是會(huì)同步的.阿蒂拉說,這比現(xiàn)在的世界要好.再說一遍,如果這樣,且個(gè)人資料顯示這是你的問題,請(qǐng)丟棄共享.

Walter說,(如果有CPU指令)可只使用CPU指令時(shí),調(diào)用std.atomic函數(shù)的效率會(huì)降低.Timon說,問題的解決方法似乎是內(nèi)在(intrinsics)的.
該提案像是內(nèi)在函數(shù),但語(yǔ)法更好.有些如何同步的決定,這樣做時(shí),會(huì)鎖定默認(rèn)語(yǔ)法.

原子負(fù)載和存儲(chǔ)的合理語(yǔ)義可能根據(jù)環(huán)境.

atila對(duì)此表示同意,但一般,這是順序一致性.
沃爾特說,這與向量指令方面問題相同.如果代碼中請(qǐng)求操作存在指令,則編譯器為你生成向量指令.如果目標(biāo)CPU上不存在該指令,則編譯器無法編譯,你可決定替代路徑.

所以,如果編譯,就會(huì)起作用.如果無法在目標(biāo)計(jì)算機(jī)上編譯,則必須找出解決方法.
Walter繼續(xù)說道,如果CPU有原子加載整數(shù)的指令,編譯器就支持它,它會(huì)給你原子加載.如果要編譯不支持整數(shù)原子負(fù)載的CPU,它無法編譯.

這正是向量指令的工作方式.在這方面取得了成功.他對(duì)此很滿意.

他說,遷移到不同平臺(tái)時(shí),也許共享代碼會(huì)中斷,也許不會(huì).但這是應(yīng)該的,因?yàn)?code>共享與CPU的構(gòu)造方式隱含在一起.所以這是應(yīng)該做的.

沃爾特

沃爾特說,已可解決DConf上出現(xiàn)的一堆問題.他對(duì)被迫為ImportC使用微軟匯編語(yǔ)法,非常失望,因?yàn)?code>他們沒有提供最終不用內(nèi)聯(lián)匯編器版本的頭文件的路徑.