d测试套件问题

原文
即,抱怨的是构建和测试的顺序.
有个测试包来测试编译器.数百个此测试.每个测试都是独立的,只有几行长.也即,已化简和隔离了它们.(大多数来源是已修复的漏洞.),当某个测试失败时,一般可直接找到问题.

但测试包的运行方式是:
1.构建编译器
2.用它编译druntime,砰,编译器崩溃了,现在你要花几个小时来消灭该问题.
3.或用它构建检查空格.砰,编译器崩溃,或检查空格崩溃.又要花几个小时.
4.或用它来引导自身.轰,它创建了崩溃的编译器,或创建的编译器很糟糕的编译代码.又是几个小时.
5.或用它来构建build.d,构建自身然后崩溃.又是几个小时.
6.或用它来构建标准库.构建标准库时崩溃,或标准库单元测试失败.又是几个小时.

或:
新编译的编译器来运行编译器测试包.test1234.d失败.只需要花几分钟时间就可确定错误所在,因为你只需要查看6行代码,而不是100,000行.
2,3,4,5,6都是经常的.

至少(大部分)编译器测试包不依赖正常工作的标准库.我(和其他人)已删除几乎所有这些依赖项.
先运行编译器测试包的另一个好处是,它相对较小且运行速度快,因此,可快速周转.