Why Phobos is cool

[Iain Buclaw]

On 17/07/2020 16:28, rikki cattermole via Digitalmars-d wrote:
> On 18/07/2020 2:14 AM, Iain Buclaw wrote:
>> Apart from std.math, there are no differences between upstream and downstream copies anyway (and I could always upstream version(GNU) asm implementations for x86, RISC-V, ...).
>>
>> It would certainly make my life easier, would speed up both time to build compiler and run the testsuite, and no more worrying about getting the mathlib working on PPC64, or PA-RISC, or M68K, or VAX.  That's now someone else's problem, and I can think of better things I could be doing with my time anyway.
>>
>> Would people be happy if I did this?  I doubt it.
> 
> How often does compiling Phobos as part of the testsuite catch bugs in gdc?
> 
> If the answer is never, then maybe some deferring could be possible.

We're usually very good at finding bugs in Phobos, rather than the other way round.

However, the combination of testsuite + druntime alone is not really representative of catching all issues that could happen on changes made to the code generator, and there have been a few fairly intrusive changes I've been testing in the last weeks where Phobos has proved to be a good litmus test for finding problems (especially in the changes being done to emission strategy - I can no longer ignore it due to newly added GC tests in druntime that depend on weak rather than vague linkage).

Though the same "representative" argument can be made of testsuite + druntime + phobos as well, and it shouldn't be too difficult to add a test script that obtains and builds a bunch of projects (similar to dmd buildkite) as a kind of expensive testsuite run.