| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
executablePath support for NetBSD was added in
a172be07e3dce758a2325104a3a37fc8b1d20c9c, but the test was not
updated.
Update the test so that it works for NetBSD. This requires handling
some quirks:
- The result of getExecutablePath could include "./" segments.
Therefore use System.FilePath.equalFilePath to compare paths.
- The sysctl(2) call returns the original executable name even after
it was deleted. Add `canQueryAfterDelete :: [FilePath]` and
adjust expectations for the post-delete query accordingly.
Also add a note to the `executablePath` haddock to advise that
NetBSD behaves differently from other OSes when the file has been
deleted.
Also accept a decrease in memory usage for T16875. On Windows, the
metric is -2.2% of baseline, just outside the allowed ±2%. I don't
see how this commit could have influenced this metric, so I suppose
it's something in the CI environment.
Metric Decrease:
T16875
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The executablePath test strips the file extension (if any) when
comparing the query result with the expected value. This is to
handle platforms where GHC adds a file extension to the output
program file (e.g. .exe on Windows).
After the initial check, the file gets deleted (if supported).
However, it tries to delete the *stripped* filename, which is
incorrect. The test currently passes only because Windows does not
allow deleting the program while any process created from it is
alive.
Make the test program correct in general by deleting the
*non-stripped* executable filename.
|
