"lit"-based test suite
Johan Engelen via digitalmars-d-ldc
digitalmars-d-ldc at puremagic.com
Sun Jan 3 16:33:17 PST 2016
On Sunday, 3 January 2016 at 18:59:16 UTC, David Nadlinger wrote:
> On 3 Jan 2016, at 19:36, Johan Engelen via digitalmars-d-ldc
> wrote:
>> - Move the LDC-specific tests from the DMD testsuite into a
>> few other ./tests/abc directories and run them with lit instead
>
> For the tests that are truly specific to LDC this certainly
> makes sense.
>
> As fas as the general D tests are concerned that just happened
> to cause an issue in the LDC glue code but not DMD, I think we
> should actually try to upstream them to the DMD testsuite, as
> other compilers will also benefit from the improved coverage.
> (Not sure whether the powers that be agree with that, though.)
> For new test cases, we could add them to the lit-based suite
> first and upstream them every so often.
Agreed.
> How suitable is the lit-based workflow for fail_compilation
> diagnostic checks? I'm not very familiar with it (yet).
For non-zero return values, there is the "not" LLVM utility:
not ldc2 compile_error.d
returns zero if ldc2 errored, and returns non-zero if ldc2
succeeded. There are many tests like that in LLVM/Clang. So then
I think you'd get something like:
// RUN: not %ldc2 %s 2&>1 | FileCheck %s
// Test error diagnostic:
// CHECK: error: bla bla.
> Another question is that of organization. Dumping everything
> (dmd testsuite runner, general CMake stuff, lit config,
> individual lit test case files) directly into tests/ might get
> a bit messy in the long run.
I want to pull lit config, lit runner, cmake stuff out of
/tests/ir, and put it in /tests. Then all testcases should go
into a subdirectory of /tests: /tests/codegen, /tests/profile,
tests/runnable, /tests/whatever.
More information about the digitalmars-d-ldc
mailing list