Monorepo?

Steven Schveighoffer schveiguy at gmail.com
Mon Feb 6 20:21:35 UTC 2023


On 2/6/23 1:36 PM, Walter Bright wrote:

> More specifically, I complained about the order in which things were 
> built and tested.
> 
> There is a test suite designed to test the compiler. There are many 
> hundreds of these tests. Each is standalone, only a few lines long. I.e. 
> they are already reduced and isolated. (The source of most of these were 
> bugs that were fixed.) When something in that test suite fails, one can 
> usually go directly to the problem.
> 
> But what happens with the way the test suite is run is:
> 
> 1. the compiler gets built
> 
> 2. then the compiler is used to compile druntime. Boom, the compiler 
> crashes. Now you've got hours of work to reduce the problem.

This is probably unavoidable. druntime and the compiler are tightly coupled.

Potentially, you could run some tests before this? Off the top of my 
head, you could run fail-compilation tests before a valid druntime is 
available?

> 3. or the compiler is used to build checkwhitespace. Boom, the compiler 
> crashes, or checkwhitespace crashes. Hours of work ahead.

We should build checkwhitespace with the bootstrap compiler, not with 
the built compiler. You can rebuild checkwhitespace at the end as a 
further test. In any case, changing the compiler shouldn't break this 
part of the step.

> 4. or the compiler is used to bootstrap itself. Boom, it creates a 
> compiler that crashes, or the created compiler compiles code badly. 
> Hours of work ahead.

This should be done after the test suite, right?

> 5. or the compiler is used to build build.d. build itself then crashes. 
> Hours of work ahead.

Same here.

> 6. or the compiler is used to build Phobos. It crashes building Phobos, 
> or the Phobos unittests fail. Hours of work ahead.

Yeah, we need to make sure phobos isn't needed to run the full test 
suite. possibly we could delay phobos-dependent tests until after the 
standalone tests finish.

Sometimes compiler bugs are only tickled with insanely convoluted 
conditions, which might include specific parts of phobos. Reducing them 
is ideal, but that takes hours too.

> the freshly built compiler is used to run the compiler test suite. 
> test1234.d fails. A few minutes of work identifying what went wrong, 
> because you've only got 6 lines of code to look at rather than 100,000 
> lines.
> 
> 2,3,4,5,6 have all routinely happened.
> 
> At least (mostly) the compiler test suite does not depend on a 
> functioning Phobos. Myself (and others) have removed nearly all of those 
> dependencies.
> 
> Another advantage of running the compiler test suite first is it is 
> relatively small and runs fast. Hence, you get quick turnaround.
> 

All agreed. We should have a standing rule that any tests that are run 
based on code external to dmd/druntime need to happen *after* all the 
dmd/druntime tests are done. And tools should be built with a known good 
compiler. The "checkwhitespace" problem seems an incredibly foolish 
requirement to shove in front of making sure you have a sane compiler.

-Steve


More information about the Digitalmars-d mailing list