Avoid any potential false positives resulting from rdmd_test being
accidentally built with -release.
Avoiding this situation is paramount, with the alternative being a
clunky runtime test to detect that rdmd_test was built with -release,
so this solution is preferable, even considering the semantic loss of
the distinction between assert/enforce and their existing usage.
Windows uses backslashes for string separators, which are rendered as
escaped in rdmd's --chatty output. Mirror this behavior to correctly
run this test on Windows, as well as other situations when the path
contains characters that would be escaped by std.format's "DSON"
formatting.
Use an empty file (instead of one containing a dummy string) to avoid
a GUI pop-up, which would otherwise need to be dismissed by an
interactive user. An empty file will just cause a "%s is not a valid
Win32 application" exception, which is similar enough to the Posix
behavior and handled properly by rdmd and the test suite.
Fixes some tests using the wrong model.
Also fixes running the test suite for DMD configurations supporting
just one model, which is not the default DMD model (e.g. those built
by Digger on Windows).
By checking only `value[0]`, the `dashOh` callback used to parse `-o...`
flags would give false positives (e.g. for `-o-foo` or `-opbar`). This
patch fixes the discrepancy by requiring exact comparison to `value`.
A few test cases have been added to `rdmd_test` to cover these failures.
Thanks to @CyberShadow for spotting the bug and proposing the fix.
This fixes a discrepancy between `rdmd` and `dmd` in terms of the output
flags they support: `dmd` now requests `-of=...` and `-od=...` in help
output but still supports the old `-of...` and `-od...` style, while
`rdmd` was still supporting only the older variant.
Thanks to @CyberShadow for suggesting the `skipOver`-based solution.
Extra test cases have been added to `rdmd_test` to cover this, although
the way this has been done is a little bit cheeky (it turns out the only
place where `-of` and `-od` are really tested rigorously is in tests for
the case where the output file is a library in a subdirectory). At some
point it would be a good idea to add some more rigorous test cases for
the `-o...` flags, but in the short term the tests added in this patch
should validate the changes to `rdmd` itself.
One key problem of the old `rdmd_test` was that it built its own rdmd
instance to test. This meant that technically, it was never actually
run against the rdmd executable generated in the regular tools build.
This rewrite fixes this by repurposing the `--rdmd` flag of `rdmd_test`
to require not a path to `rdmd.d` but a path to the rdmd executable for
which the test suite should be run. The provided executable is not used
directly, but is copied into a temporary directory: this is necessary in
order to run the fallback test, which involves copying a dummy compiler
into the same directory as the tested rdmd executable.
The `--compiler` flag has been removed (since `rdmd_test` no longer uses
it to build rdmd), but a new `--rdmd-default-compiler` flag is required
in order to specify the name of the default compiler for by the tested
rdmd. This is needed in order to carry out the fallback compiler test,
which will fail if the provided name does not match that of the default
compiler used by the rdmd executable.
The `test_rdmd` target in `posix.mak` has been reworked to use the new
`--rdmd` and `--rdmd-default-compiler` flags. By default these will be
invoked with the generated `rdmd` instance and the name of the compiler
used to build it, but these choices can be customized respectively with
the new `RDMD_TEST_EXECUTABLE` and `RDMD_TEST_DEFAULT_COMPILER` make
variables.
This should ensure that the rdmd instance generated by the regular build
is properly tested, while allowing `rdmd_test` to be used with arbitrary
`rdmd` instances if any developer should wish to do so.
Top-level module documentation has been tweaked to reflect the new flags
and intended usage, and help information has been added to the `getopt`
call, which will be output if the `-h|--help` flag is used, or if the
user fails to supply the required `--rdmd` or `--rdmd-default-compiler`
flags.
There is no need for `rdmd_test` to manually remove any pre-existing
`/tmp/rdmd_app_`, since we are going to overwrite it anyway, but it
is good housekeeping to clean it up on exit.
This patch updates travis.sh to install GDC and to include the DMD-alike
`gdmd` compiler frontend among the `RDMD_TEST_COMPILERS`.
Since GDC does not yet implement `pragma(lib)`, the `rdmd_test` case for
this has been disabled for the case where `gdmd` is the test compiler
(see: https://issues.dlang.org/show_bug.cgi?id=18421). This workaround
reflects the fact that the test is of the correctness in how `rdmd` uses
a D compiler with `pragma(lib)` support, rather than of `pragma(lib)` in
itself. The constraint can be removed once GDC supports `pragma(lib)`.
This is a little bit bikesheddy but helps to emphasize the distinction
between the compiler used to build rdmd, and the compiler(s) invoked by
rdmd when running the test suite.
Note that the `--compiler` flag of `rdmd_test` has been left unchanged
so as not to risk breaking changes for users.
This new flag can be used to specify the list of different compilers for
`rdmd` to invoke when running the test suite. This can be provided as a
single compiler name, or as a comma-separated list, e.g.
--test-compilers=dmd,gdmd,ldmd2
The complete test suite will be run for each of the specified compilers.
If the flag is not supplied, then the test suite will be run for the
same compiler as was used to build `rdmd` (as specified by `rdmd_test`'s
`--compiler` flag).
The test for the fallback to default compiler is still invoked only with
respect to the build compiler, since by its very nature this involves a
search for only the one compiler name (determed when `rdmd` is built).
This makes it easier to ensure that the test suite can be run for many
different choices of these parameters.
The `verbose` parameter has been left as global because it seems less
likely that this might need to be customizable for different runs of the
test suite.
The existing rdmd_test script assumes that the compiler invoked by rdmd
when running tests is the same as the compiler used to build rdmd, and
that it targets the same build model. This helper function should make
it easier to construct tests that use different compiler and/or model
settings.
If no explicit `--compiler` flag is passed, `rdmd` should first search
for its default compiler (determined by the compiler used to build it)
in the same directory that it itself lives in.
The test of this behaviour is unique inasmuch as, unlike all other tests
implemented by `rdmd_test`, it alone explicitly involves a case where
`rdmd` is searching for a single compiler name. It must therefore be
separated out from all the other tests if we want to be able to rework
them to run with multiple different compilers (which clearly requires
use of the `--compiler` flag).
The new `runFallbackTest` function has been implemented so as to avoid
having any dependencies on global state, since this will simplify future
changes required by multi-compiler tests.
The original versions of these functions assume a single, global choice
for compiler and model. By requiring the compiler or model choice to be
passed as input we can more readily rework the rest of the test suite to
test rdmd with different compiler or model choices.
