GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-12-21T15:37:43Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/20832Testsuite driver: Don’t do `/test spaces/` by default2021-12-21T15:37:43ZJoachim Breitnermail@joachim-breitner.deTestsuite driver: Don’t do `/test spaces/` by defaultThe testsuite driver sets `TEST_HC` to a path with spaces to catch mistakes (unquoted `$(TEST_HC)` in Makefiles), as described in `testsuite/mk/boilerplate.mk`. This is laudable, but mildly annoying during local development; it makes alr...The testsuite driver sets `TEST_HC` to a path with spaces to catch mistakes (unquoted `$(TEST_HC)` in Makefiles), as described in `testsuite/mk/boilerplate.mk`. This is laudable, but mildly annoying during local development; it makes already noisy log lines even noisier and longer and harder to select.
I suggest to make this optional, e.g. instead of or as part of
```
ifneq "$(wildcard $(STAGE1_TEST_SPACES))" ""
```
also check if some flag/variable is set that opts-into this behavior, and then set that flag in CI, but not by default. WDYT?Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16361Non-deterministic hs_try_putmvar003 failure on CI2021-11-01T17:02:28ZVladislav ZavialovNon-deterministic hs_try_putmvar003 failure on CI```
Wrong exit code for hs_try_putmvar003(threaded1)(expected 0 , actual 139 )
*** unexpected failure for hs_try_putmvar003(threaded1)
```
A quick search suggests that 139 might mean a segfault (SIGSEGV).
This is a non-deterministic CI...```
Wrong exit code for hs_try_putmvar003(threaded1)(expected 0 , actual 139 )
*** unexpected failure for hs_try_putmvar003(threaded1)
```
A quick search suggests that 139 might mean a segfault (SIGSEGV).
This is a non-deterministic CI failure that happened to me at least two times (Feb 12 and Feb 24), and forced me to restart the build job to get a green build status. Both times it was the `validate-x86_64-linux-fedora27` job, but on different runners (`ghc-ci-gce-x86_64-1` and `maurer.smart-cactus.org`).
Note that another failure that seems to happen only on Fedora is #16350 – could it be a problem with the Fedora image?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------------- |
| Version | 8.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | RyanGlScott, bgamari, mpickering |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Non-deterministic hs_try_putmvar00 failure on CI","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["RyanGlScott","bgamari","mpickering"],"type":"Bug","description":"{{{\r\nWrong exit code for hs_try_putmvar003(threaded1)(expected 0 , actual 139 )\r\n*** unexpected failure for hs_try_putmvar003(threaded1)\r\n}}}\r\n\r\nA quick search suggests that 139 might mean a segfault (SIGSEGV).\r\n\r\nThis is a non-deterministic CI failure that happened to me at least two times (Feb 12 and Feb 24), and forced me to restart the build job to get a green build status. Both times it was the `validate-x86_64-linux-fedora27` job, but on different runners (`ghc-ci-gce-x86_64-1` and `maurer.smart-cactus.org`).\r\n\r\nNote that another failure that seems to happen only on Fedora is #16350 – could it be a problem with the Fedora image?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/20192GHC 9.0.1 testsuite crash2021-08-03T18:04:42ZStefan Schulze FrielinghausGHC 9.0.1 testsuite crash## Summary
Running a multi-threaded testsuite using GHC 9.0.1 results _always_ in an error on s390x:
```
./hadrian/build -j2 test
...
=====> GADT11(normal) 2289 of 7742 [0, 1, 0]
=====> GADT12(normal) 2289 of 7742 [0, 1, 0]
Error when ...## Summary
Running a multi-threaded testsuite using GHC 9.0.1 results _always_ in an error on s390x:
```
./hadrian/build -j2 test
...
=====> GADT11(normal) 2289 of 7742 [0, 1, 0]
=====> GADT12(normal) 2289 of 7742 [0, 1, 0]
Error when running Shake build system:
at want, called at src/Main.hs:102:30 in main:Main
* Depends on: test
* Raised the exception:
fd:5: hGetLine: invalid argument (invalid byte sequence)
```
This is not the case if run in single-threaded mode, i.e., with `-j1`. Multi-threaded testsuite runs fine using GHC 8.10 and Mainline. Furthermore, the crash happens at different tests and at different times. Thus there is no clear pattern.
A bootstrap using 9.0.1 in order to build 9.0.1 works perfectly fine. Therefore, GHC itself seems to be fine.
Is there any way to get an exception trace in order to narrow down the program point where the exception occurs?
## Steps to reproduce
```
./hadrian/build -j2 test
```
or basically any `-jN` where `N>1`.
## Environment
* GHC version used: Tried a couple of versions from 9.0.1-rc1 up to 1b5418b7a8
Optional:
* Operating System: Fedora 33
* System Architecture: s390xhttps://gitlab.haskell.org/ghc/ghc/-/issues/16813T15633b is fragile on Windows2021-06-21T09:36:49ZBen GamariT15633b is fragile on WindowsIn !1130 I saw one build where `T15633b` failed segfaulted on Windows:
```
Wrong exit code for T15633b(ghci)(expected 0 , actual 11 )
Stdout ( T15633b ):
True
Stderr ( T15633b ):
TcPluginGHCi
Access violation in generated code when rea...In !1130 I saw one build where `T15633b` failed segfaulted on Windows:
```
Wrong exit code for T15633b(ghci)(expected 0 , actual 11 )
Stdout ( T15633b ):
True
Stderr ( T15633b ):
TcPluginGHCi
Access violation in generated code when reading 0xfffffffffffffff8
Attempting to reconstruct a stack trace...
Frame Code address
* 0x54ffaf0 0x3001263 C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2c01263
* 0x54ffb70 0x2fd578c C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bd578c
* 0x54ffbe0 0x2fcacbf C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bcacbf
* 0x54ffd30 0x2fcb63f C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bcb63f
* 0x54ffe20 0x2fc0270 C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bc0270
* 0x54ffed0 0x2fc11c7 C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bc11c7
* 0x54fff10 0x2fc1a4f C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2bc1a4f
* 0x54fff50 0x2fe92f8 C:\GitLabRunner\builds\e963ee11\0\ghc\ghc\inplace\bin\ghc-stage2.exe+0x2be92f8
* 0x54fff80 0x7ffef5d284d4 C:\Windows\System32\KERNEL32.DLL+0x84d4
* 0x54fffd0 0x7ffef86be851 C:\Windows\SYSTEM32\ntdll.dll+0x6e851
*** unexpected failure for T15633b(ghci)
```
I suspect this means that either plugins or GHCi (or the combination of the two) are fragile on Windows. I'm going to mark both `T15633b` and `T15633a` as fragile on Windows.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/18605Integrate Parsley into testsuite / head.hackage somehow?2021-05-23T22:39:57ZRichard Eisenbergrae@richarde.devIntegrate Parsley into testsuite / head.hackage somehow?I just watched Nick Wu and Jamie Willis's talk on *Staged Selective Parser Combinators*. The implementation, https://github.com/J-mie6/ParsleyHaskell, uses Typed Template Haskell, levity polymorphism, heterogeneous lists, and likely othe...I just watched Nick Wu and Jamie Willis's talk on *Staged Selective Parser Combinators*. The implementation, https://github.com/J-mie6/ParsleyHaskell, uses Typed Template Haskell, levity polymorphism, heterogeneous lists, and likely other pyrotechnics. We should use it as a benchmark for GHC -- including a performance one, given that the runtime performance of their parser library is one of their goals.https://gitlab.haskell.org/ghc/ghc/-/issues/19671Make hadrian refuse to test when flavour is quick (or devel2 or ...)2021-04-09T08:48:33ZOleg GrenrusMake hadrian refuse to test when flavour is quick (or devel2 or ...)I have bitten by that twice recently:
- https://gitlab.haskell.org/ghc/ghc/-/issues/19669
- https://gitlab.haskell.org/ghc/ghc/-/issues/19356
As this configuration (running tests with quick flavour) that should be actively discouraged. ...I have bitten by that twice recently:
- https://gitlab.haskell.org/ghc/ghc/-/issues/19669
- https://gitlab.haskell.org/ghc/ghc/-/issues/19356
As this configuration (running tests with quick flavour) that should be actively discouraged. If someone really needs, there could be a flag `--trust-me` to run tests with flavours which are not tested on CI.
---
Running test suite with flavour=devel2 results in
```
ghc: Could not load Object Code /code/ghc-asum/_build_master/stage1/lib/x86_64-linux-ghc-9.1.20210408/ghci-9.1/HSghci-9.1.o.
ghc: unable to load unit `ghci-9.1'
```
I'm not going to open issue about that, but it shows my point. Devel2 is recommended in https://gitlab.haskell.org/ghc/ghc/-/wikis/building/quick-start which you land through https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#first-stepshttps://gitlab.haskell.org/ghc/ghc/-/issues/19525getGroupEntryForName gives different result on WSL22021-04-06T14:45:03ZSimon Peyton JonesgetGroupEntryForName gives different result on WSL2I’ve just installed WSL2 and built GHC.
I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can’t push a change to master because that’ll affect everyon...I’ve just installed WSL2 and built GHC.
I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can’t push a change to master because that’ll affect everyone else.
Any ideas?
```
=====> 1 of 1 [0, 0, 0]
]0;getGroupEntryForName(normal) 1 of 1 [0, 0, 0]Actual stderr output differs from expected:
--- getGroupEntryForName.run/getGroupEntryForName.stderr.normalised 2021-03-09 22:36:01.300421100 +0000
+++ getGroupEntryForName.run/getGroupEntryForName.run.stderr.normalised 2021-03-09 22:36:01.300421100 +0000
@@ -1 +1 @@
-getGroupEntryForName: getGroupEntryForName: does not exist (no such group)
+getGroupEntryForName: getGroupEntryForName: does not exist (No such process)
*** unexpected failure for getGroupEntryForName(normal)
```
For info, about my system:
```
bash$ uname -a
Linux MSRC-3645512 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
bash$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
```https://gitlab.haskell.org/ghc/ghc/-/issues/18514Hadrian: Warn when running hadrian --flavour=quickest test2021-03-29T17:12:20ZtoonnHadrian: Warn when running hadrian --flavour=quickest test## Motivation
It would be great if hadrian warned when running the test target with the quickest flavour.
## Proposal
I just ran into #12141. I'd never touched `mk/build.mk` as my needs are limited.
There's very little warning against...## Motivation
It would be great if hadrian warned when running the test target with the quickest flavour.
## Proposal
I just ran into #12141. I'd never touched `mk/build.mk` as my needs are limited.
There's very little warning against running the testsuite when using the quickest flavour. It's only documented in `mk/build.mk`.
The tests I did need to run while developing a patch weren't affected by the build flavour so the final sanity check was the only opportunity for this to surface.
If hadrian test could emit a warning at the start and either the end or the result summary about test results not being reliable when run with the quickest flavour such confusion could be avoided in the future.https://gitlab.haskell.org/ghc/ghc/-/issues/17387Use higher resolution for max residency measurements in performance tests.2021-03-29T13:39:37ZAndreas KlebingerUse higher resolution for max residency measurements in performance tests.## Motivation
GHC has quite a few performance tests, some of those measuring max residency.
However residency is a notoriously unreliable metric.
## Proposal
Use RTS flags like `+RTS -h -i0 -A100k` to tune the frequency of residency ...## Motivation
GHC has quite a few performance tests, some of those measuring max residency.
However residency is a notoriously unreliable metric.
## Proposal
Use RTS flags like `+RTS -h -i0 -A100k` to tune the frequency of residency snapshots (at the cost of runtime for the test).
The exact frequency can also be tuned via higher or lower allocation area (or actual -i times other than zero).
It won't change the fact that it will be a unreliable metric, but it should make it less so.https://gitlab.haskell.org/ghc/ghc/-/issues/18985T5866 fails spuriously2021-03-27T13:18:54ZBen GamariT5866 fails spuriouslyI have seen T5866 fail on Windows
[here](https://gitlab.haskell.org/ghc/ghc/-/jobs/505810) with:
```patch
--- "C:/GitLabRunner/builds/ux46CNax/0/ghc/ghc/tmp/ghctest-3z5t1nrm/test spaces/testsuite/tests/concurrent/should_run/T5866.run/...I have seen T5866 fail on Windows
[here](https://gitlab.haskell.org/ghc/ghc/-/jobs/505810) with:
```patch
--- "C:/GitLabRunner/builds/ux46CNax/0/ghc/ghc/tmp/ghctest-3z5t1nrm/test spaces/testsuite/tests/concurrent/should_run/T5866.run/T5866.stderr.normalised" 2020-11-24 13:24:19.913012500 +0000
+++ "C:/GitLabRunner/builds/ux46CNax/0/ghc/ghc/tmp/ghctest-3z5t1nrm/test spaces/testsuite/tests/concurrent/should_run/T5866.run/T5866.run.stderr.normalised" 2020-11-24 13:24:19.913012500 +0000
@@ -1 +0,0 @@
-T5866: thread blocked indefinitely in an STM transaction
```
I'm reasonably confident that this patch is not at fault.https://gitlab.haskell.org/ghc/ghc/-/issues/19505./validate results in many (>400) spurious failed tests on windows locally.2021-03-11T14:41:11ZAndreas Klebinger./validate results in many (>400) spurious failed tests on windows locally.Most (all?) failures seem to be from makefile tests. I assume we don't quote something quite right.
The errors are something like:
```
=====> concio001(normal) 8036 of 8039 [0, 483, 0]
cd "C:/Users/andi/AppData/Local/Temp/ghctest-6b8pf...Most (all?) failures seem to be from makefile tests. I assume we don't quote something quite right.
The errors are something like:
```
=====> concio001(normal) 8036 of 8039 [0, 483, 0]
cd "C:/Users/andi/AppData/Local/Temp/ghctest-6b8pfckv/test spaces/libraries/base/tests/IO/concio001.run" && $MAKE -s --no-print-directory test.concio001 <
Actual stderr output differs from expected:
diff -uw "/dev/null" "C:/Users/andi/AppData/Local/Temp/ghctest-6b8pfckv/test spaces/libraries/base/tests/IO/concio001.run/concio001.run.stderr.normalised"<
--- /dev/null 2021-03-08 14:42:58.000000000 +0100
+++ "C:/Users/andi/AppData/Local/Temp/ghctest-6b8pfckv/test spaces/libraries/base/tests/IO/concio001.run/concio001.run.stderr.normalised" 2021-03-08 14:42:58.529778900 +0100
@@ -0,0 +1,3 @@
+/bin/sh: line 1: [: C://ghc//msys64//home//andi//ghc_strictDicts//bindisttest//install: binary operator expected
+/bin/sh: line 1: [: C://ghc//msys64//home//andi//ghc_strictDicts//bindisttest//install: binary operator expected
+/bin/sh: line 1: [: C://ghc//msys64//home//andi//ghc_strictDicts//bindisttest//install: binary operator expected
```
And in the list of unexpected failures:
```
Unexpected failures:
C:/Users/andi/AppData/Local/Temp/ghctest-6b8pfckv/test spaces/testsuite/tests/ghc-api/apirecomp001/apirecomp001.run apirecomp001 [bad stderr] (normal)
C:/Users/andi/AppData/Local/Temp/ghctest-6b8pfckv/test spaces/testsuite/tests/module/base01/base01.run base01 [bad stderr] (normal)
C:/Users/andi/AppData/Local/Temp/ghctest-6b8pfckv/test spaces/testsuite/tests/ghci/linking/dyn/big-obj.run big-obj [bad stderr] (normal)
C:/Users/andi/AppData/Local/Temp/ghctest-6b8pfckv/test spaces/testsuite/tests/backpack/cabal/bkpcabal01/bkpcabal01.run bkpcabal01 [bad stderr] (normal)
```
the `spaces` prefix seems suspicious. Maybe the way hadrian invokes the testsuite somehow breaks make tests? Not sure.https://gitlab.haskell.org/ghc/ghc/-/issues/17945T12971 is broken on Windows2021-03-08T15:44:46ZBen GamariT12971 is broken on Windows*This was originally tracked in #17943*.
Currently `T12971` fails inexplicably on Windows:
```
Wrong exit code for T12971()(expected 0 , actual 2 )
Stdout ( T12971 ):
[1 of 1] Compiling Main ( T12971.hs, T12971.o )
Linking T...*This was originally tracked in #17943*.
Currently `T12971` fails inexplicably on Windows:
```
Wrong exit code for T12971()(expected 0 , actual 2 )
Stdout ( T12971 ):
[1 of 1] Compiling Main ( T12971.hs, T12971.o )
Linking T12971.exe ...
Stderr ( T12971 ):
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.11.0.20200320:
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
ghc.exe: fd:5: hGetContents: invalid argument (invalid byte sequence)
make: *** [Makefile:670: T12971] Error 1
*** unexpected failure for T12971(normal)
```
The issue appears to be an encoding issue; I suspect the issue is the `hGetContents` call in `SysTools.Process.readCreateProcessWithExitCode'` in particular.
However, neither forcing use of the 65001 codepage nor forcing the encoding of the `outh` handle in `readCreateProcessWithExitCode'` seem to avoid the issue:
```patch
diff --git a/compiler/main/SysTools/Process.hs b/compiler/main/SysTools/Process.hs
index aa5d6617d3..a23d529132 100644
--- a/compiler/main/SysTools/Process.hs
+++ b/compiler/main/SysTools/Process.hs
@@ -55,7 +55,10 @@ readCreateProcessWithExitCode' proc = do
createProcess proc{ std_out = CreatePipe }
-- fork off a thread to start consuming the output
+ putStrLn "hello1"
+ hSetEncoding outh utf8
output <- hGetContents outh
+ putStrLn "hello2"
outMVar <- newEmptyMVar
_ <- forkIO $ evaluate (length output) >> putMVar outMVar ()
```
Even stranger, I am unable to reproduce the issue outside of the testsuite driver.
Stranger still, the test still fails even if I modify the test definition to remove any sign of non-7-bit characters from `TMP`:
```patch
diff --git a/testsuite/tests/driver/Makefile b/testsuite/tests/driver/Makefile
index 77a77c158d..07577cfb5e 100644
--- a/testsuite/tests/driver/Makefile
+++ b/testsuite/tests/driver/Makefile
@@ -666,8 +666,8 @@ T12955:
.PHONY: T12971
T12971:
- mkdir -p ä
- TMP=ä "$(TEST_HC)" $(TEST_HC_OPTS) --make T12971
+ mkdir -p a
+ TMP=a "$(TEST_HC)" -v3 -optc-fno-diagnostics-color $(TEST_HC_OPTS) --make T12971
.PHONY: T14452
T14452:
```
However, the failure *does* vanish if I remove the `TMP=a` from the test's command-line entirely.
Given that this really isn't a critical issue, I'm going to mark this test as broken.https://gitlab.haskell.org/ghc/ghc/-/issues/19488T14999 fails with quick build flavour2021-03-04T22:16:58ZRyan ScottT14999 fails with quick build flavourIf I run the `T14999` test case using a `quick` build of GHC, it fails with:
```
=====> 1 of 1 [0, 0, 0]
Actual stdout output differs from expected:
--- codeGen/should_compile/T14999.run/T14999.stdout.normalised 2021-03-04 13:28:51.648...If I run the `T14999` test case using a `quick` build of GHC, it fails with:
```
=====> 1 of 1 [0, 0, 0]
Actual stdout output differs from expected:
--- codeGen/should_compile/T14999.run/T14999.stdout.normalised 2021-03-04 13:28:51.648586079 -0500
+++ codeGen/should_compile/T14999.run/T14999.run.stdout.normalised 2021-03-04 13:28:51.648586079 -0500
@@ -1,6 +1,6 @@
Dump of assembler code for function stg_catch_frame_info:
- 0x0000000000000010 <+0>: add $0x18,%rbp
- 0x0000000000000014 <+4>: jmpq *0x0(%rbp)
+ 0x0000000000000010 <+1>: add $0x18,%rbp
+ 0x0000000000000014 <+5>: jmpq *0x0(%rbp)
End of assembler dump.
Contents of the .debug_frame section:
00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16
*** unexpected failure for T14999(normal)
Performance Metrics (test environment: local):
None collected.
Unexpected results from:
TEST="T14999"
SUMMARY for test run started at Thu Mar 4 13:28:51 2021
0:00:00.392025 spent to go through
1 total tests, which gave rise to
10 test cases, of which
6 were skipped
0 had missing libraries
0 expected passes
0 expected failures
0 caused framework failures
0 caused framework warnings
0 unexpected passes
1 unexpected failures
0 unexpected stat failures
0 fragile tests
Unexpected failures:
codeGen/should_compile/T14999.run T14999 [bad stdout] (normal)
```
Since this failure doesn't occur on CI, I can only assume that this depends on something specific to `quick`.https://gitlab.haskell.org/ghc/ghc/-/issues/17607T17073 fails on Windows2021-03-01T02:34:57ZBen GamariT17073 fails on Windows```
=====> T17073(hpc) 2152 of 7299 [0, 0, 0]
cd "hpc/T17073.run" && $MAKE -s --no-print-directory T17073 HPC="/c/GitLabRunner/builds/78d7d3f9/0/ghc/ghc/inplace/bin/hpc.exe" <
Wrong exit code for T17073()(expected 0 , actual 2 )
Stdou...```
=====> T17073(hpc) 2152 of 7299 [0, 0, 0]
cd "hpc/T17073.run" && $MAKE -s --no-print-directory T17073 HPC="/c/GitLabRunner/builds/78d7d3f9/0/ghc/ghc/inplace/bin/hpc.exe" <
Wrong exit code for T17073()(expected 0 , actual 2 )
Stdout ( T17073 ):
Добрый день
Error: unable to find tix file for:T17073
Usage: hpc report [OPTION] .. <TIX_FILE> [<MODULE> [<MODULE> ..]]
Output textual report about program coverage
Options:
--per-module show module level detail
--decl-list show unused decls
--exclude=[PACKAGE:][MODULE] exclude MODULE and/or PACKAGE
--include=[PACKAGE:][MODULE] include MODULE and/or PACKAGE
--srcdir=DIR path to source directory of .hs files
multi-use of srcdir possible
--hpcdir=DIR append sub-directory that contains .mix files
default .hpc [rarely used]
--reset-hpcdirs empty the list of hpcdir's
[rarely used]
--xml-output show output in XML
--verbosity=[0-2] verbosity level, 0-2
default 1
Stderr ( T17073 ):
make[2]: *** [Makefile:14: T17073] Error 1
*** unexpected failure for T17073(hpc)
```Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/19430GivenCheck fails in hpc way2021-02-24T01:59:15ZBen GamariGivenCheck fails in hpc wayCurrently the `GivenCheck` and `GivenCheckSwap` tests fail in the `hpc` way. `GivenCheck` is supposed to verify that a simple program with unreachable code throws an unreachable code warning:
```haskell
type family S x
f :: a -> S a
f =...Currently the `GivenCheck` and `GivenCheckSwap` tests fail in the `hpc` way. `GivenCheck` is supposed to verify that a simple program with unreachable code throws an unreachable code warning:
```haskell
type family S x
f :: a -> S a
f = undefined
g :: S a ~ Char => a -> Char
g y | False = f y
| otherwise = 'a'
```
In the normal way the `case` of `g` produces the following pre-optimised Core (`-ddump-ds-preopt`):
```haskell
case GHC.Types.False of wild_00 {
False -> fail_dKd GHC.Prim.void#;
True ->
(f @a_aHn y_auo) `cast` (Sub co_aI6 :: S a_aHn[sk:1] ~R# Char)
}
}
```
However, in the `hpc` way it produces:
```haskell
case hpc<GivenCheckSwapMain,4>
case GHC.Types.False of t1_dKd {
False -> hpc<GivenCheckSwapMain,3> GHC.Types.False;
True -> hpc<GivenCheckSwapMain,2> GHC.Types.True
}
of wild_00 {
False -> fail_dKg GHC.Prim.void#;
True ->
hpc<GivenCheckSwapMain,6>
(f @a_aHn (hpc<GivenCheckSwapMain,5> y_auo))
`cast` (Sub co_aI6 :: S a_aHn[sk:1] ~R# Char)
}
```
This is enough to hide the fact that the case is unreachable from the pattern match checker.https://gitlab.haskell.org/ghc/ghc/-/issues/18391foreignInterruptible is fragile2021-02-22T23:27:17ZBen GamariforeignInterruptible is fragileRecently I have observed numerous failures of `foreignInterruptible` in the `ghci` way:
```
=====> foreignInterruptible(ghci) 558 of 7594 [0, 0, 0]
cd "concurrent/should_run/foreignInterruptible.run" && "/builds/Phyx/ghc/inplace/bin/ghc...Recently I have observed numerous failures of `foreignInterruptible` in the `ghci` way:
```
=====> foreignInterruptible(ghci) 558 of 7594 [0, 0, 0]
cd "concurrent/should_run/foreignInterruptible.run" && "/builds/Phyx/ghc/inplace/bin/ghc-stage2" foreignInterruptible.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -with-rtsopts=--io-manager=native -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS < foreignInterruptible.genscript
Wrong exit code for foreignInterruptible(ghci) (expected 0 , actual 1 )
Stdout ( foreignInterruptible ):
newThread started
fail
Stderr ( foreignInterruptible ):
foreignInterruptible: still waiting
*** unexpected failure for foreignInterruptible(ghci)
```
I'm not sure what changed recently as I swear this wasn't a common failure a few months ago.https://gitlab.haskell.org/ghc/ghc/-/issues/19219Testrunner: Allocation report should display change even if it is to be accepted2021-01-30T18:40:14ZSebastian GrafTestrunner: Allocation report should display change even if it is to be acceptedWhen I accept a `Metric Increase` or `Metric Decrease`, I no longer see the difference in allocations in the report, although I might still be interested in seeing it. For example if I added a subsequent commit that might have improved a...When I accept a `Metric Increase` or `Metric Decrease`, I no longer see the difference in allocations in the report, although I might still be interested in seeing it. For example if I added a subsequent commit that might have improved a decrease (`-7%` to `-42%`) or worsened an increase (`+2%` to `+38%`).
What I see instead is just an empty "Baseline value" column, the updated "New value" column, an empty "Change" column and a `NEW` indicator to the right, e.g.
```
T12234(optasm) ghc/alloc 66201040.0 65881488.0 -0.5%
T12425(optasm) ghc/alloc 111459288.0 NEW
T12545(normal) ghc/alloc 1865187560.0 NEW
T12707(normal) ghc/alloc 1065552962.0 1060568144.0 -0.5%
```
I don't particularly care for the Baseline, but I *do* care for the Change in percent.https://gitlab.haskell.org/ghc/ghc/-/issues/19185Verifying fusion in base using inspection-testing2021-01-07T18:50:10ZBen GamariVerifying fusion in base using inspection-testingCurrently `base` includes quite a few rewrite rules for fusion (e.g. `foldr/build`) and other optimisations. However, beyond our performance testsuite and periodic manual inspection of Core, little is done to verify that this machinery d...Currently `base` includes quite a few rewrite rules for fusion (e.g. `foldr/build`) and other optimisations. However, beyond our performance testsuite and periodic manual inspection of Core, little is done to verify that this machinery does not regress. @nomeata's `inspection-testing` package provides a great tool for testing this sort of thing. We should consider adding a suite of `inspection-testing` checks to the testsuite.
The biggest challenge here will be that of keeping `inspection-testing` itself up-to-date with GHC.https://gitlab.haskell.org/ghc/ghc/-/issues/18692Perf tests can be silently skipped2020-12-02T00:57:44ZKrzysztof GogolewskiPerf tests can be silently skippedSometimes, performance tests are silently skipped because of a missing baseline. For example, in !3988 we've changed the name of an environment, which made past results unavailable. (To see this, compare the performance metrics section f...Sometimes, performance tests are silently skipped because of a missing baseline. For example, in !3988 we've changed the name of an environment, which made past results unavailable. (To see this, compare the performance metrics section for the first and second commit in `validate-x86_64-linux-deb9-unreg-hadrian`. Both builds are green.)
I think this can bite us in the future - we should require indicating that the metric is missing in the commit message, just like we require indicating a metric increase or decrease. Alternatively, instead of doing this for every test, we might require a blanket indication "This commit has missing baseline values".https://gitlab.haskell.org/ghc/ghc/-/issues/18884T13702 fails with ThreadSanitizer2020-12-01T17:48:56ZBen GamariT13702 fails with ThreadSanitizer`T13702` fails when ThreadSanitizer is in use:
```
Wrong exit code for T13702()(expected 0 , actual 2 )
Stdout ( T13702 ):
Makefile:62: rec...`T13702` fails when ThreadSanitizer is in use:
```
Wrong exit code for T13702()(expected 0 , actual 2 )
Stdout ( T13702 ):
Makefile:62: recipe for target 'T13702' failed
Stderr ( T13702 ):
FATAL: ThreadSanitizer: unexpected memory mapping 0x55b4e8649000-0x55b4e864b000
make: *** [T13702] Error 66
*** unexpected failure for T13702(normal)
```
I suspect that this is a ThreadSanitizer limitation.