This PR adds built-in unit tests to the Window CI test suite. It follows-on PR #313, which successfully got a dub compile and build to run. At present the built-in unit tests are run on DMD only. LDC produces a small number of deltas due to differences in format output (more detail below).
Using make unittest has the effect of running all the built-in unit tests (in the source code files). However, it does not run the command line test suite (make test). The built-in unit tests are a substantial indication of progress though.
This PR makes a number of small code changes to accommodate Windows. The main changes where:
Disallowed implicit conversions from long to uint. These cases do not surface on MacOS or Linux builds. May be related to 32-bit Windows builds (the default).
Explicitly closing files opened as part of unit tests. This showed up in the unit tests of many tools. The most clearest cause is when rmdirRecurse is used to delete all the temporary files created during the unit test. On Windows, out-of-scope references are apparently not getting cleaned up quick enough, generating a failure. There may be other cases as well.
All cases of I/O were changed to use binary mode rather than text mode. This puts the tools in the position of using Unix newlines on all platforms, including Windows. This may or may not be the ultimate policy, but it is by far the fastest way to get started. See issue #310 for further discussion of newline handling on Windows.
The std.format.format function produces result that are inconsistence the Linux/MacOS builds. In particular, the f format with a precision value is truncating rather than rounding on Windows platforms. This is a bug. To make the unittest suite pass a set of unit tests for formatNumber in numerics.d were disabled on Windows builds. The DMD and LDC compilers produce different deltas, but both produce incorrect values. This is causing some unittest failures in tsv-sample unittests under LDC that don't occur with DMD.
An attempt was to run command line tests with make test. This will take more work, because the error tests produce Windows newline results on Windows, but the gold set was generated On Unix. It will take more time to identify a reasonable way to rectify these cases without also compromising the non-error tests. (Error messages, help messages, etc., should generate Windows newlines, on Windows, even if regular TSV results output generates Unix newlines.
Overall these changes go a long way towards having a solid Windows test platform.
This PR adds built-in unit tests to the Window CI test suite. It follows-on PR #313, which successfully got a
dubcompile and build to run. At present the built-in unit tests are run on DMD only. LDC produces a small number of deltas due to differences informatoutput (more detail below).Using
make unittesthas the effect of running all the built-in unit tests (in the source code files). However, it does not run the command line test suite (make test). The built-in unit tests are a substantial indication of progress though.This PR makes a number of small code changes to accommodate Windows. The main changes where:
rmdirRecurseis used to delete all the temporary files created during the unit test. On Windows, out-of-scope references are apparently not getting cleaned up quick enough, generating a failure. There may be other cases as well.std.format.formatfunction produces result that are inconsistence the Linux/MacOS builds. In particular, thefformat with a precision value is truncating rather than rounding on Windows platforms. This is a bug. To make the unittest suite pass a set of unit tests forformatNumberinnumerics.dwere disabled on Windows builds. The DMD and LDC compilers produce different deltas, but both produce incorrect values. This is causing some unittest failures intsv-sampleunittests under LDC that don't occur with DMD.An attempt was to run command line tests with
make test. This will take more work, because the error tests produce Windows newline results on Windows, but the gold set was generated On Unix. It will take more time to identify a reasonable way to rectify these cases without also compromising the non-error tests. (Error messages, help messages, etc., should generate Windows newlines, on Windows, even if regular TSV results output generates Unix newlines.Overall these changes go a long way towards having a solid Windows test platform.