GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:04:36Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15469Validation doesn't play nicely on a shared computer2019-07-07T18:04:36ZRichard Eisenbergrae@richarde.devValidation doesn't play nicely on a shared computerIn my shared Linux server, validation creates a directory structure under `/tmp` to do its work. It then creates a directory named something like `ghctest-52ezqtk2` under which the tests live. However, some of the tests in the testsuite ...In my shared Linux server, validation creates a directory structure under `/tmp` to do its work. It then creates a directory named something like `ghctest-52ezqtk2` under which the tests live. However, some of the tests in the testsuite are library tests. These end up in a `libraries` directory, accessed with prefixes like `../../libraries/xyz`. That is, the `libraries` directory ends up to be `/tmp/libraries`. The problem is that I share this Linux server with my students, who are also attempting to run validation. After the occasional cleanout of `/tmp`, whoever validates first creates the `/tmp/libraries` directory and then owns that directory -- anyone else who tries to validate gets permission errors until the next cleanout of `tmp`.
Even with the presumably quick fix of changing the permissions on `libraries`, the very use of that folder means that two people cannot validate simultaneously on the same machine.
Can we fix this?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Validation doesn't play nicely on a shared computer","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In my shared Linux server, validation creates a directory structure under `/tmp` to do its work. It then creates a directory named something like `ghctest-52ezqtk2` under which the tests live. However, some of the tests in the testsuite are library tests. These end up in a `libraries` directory, accessed with prefixes like `../../libraries/xyz`. That is, the `libraries` directory ends up to be `/tmp/libraries`. The problem is that I share this Linux server with my students, who are also attempting to run validation. After the occasional cleanout of `/tmp`, whoever validates first creates the `/tmp/libraries` directory and then owns that directory -- anyone else who tries to validate gets permission errors until the next cleanout of `tmp`.\r\n\r\nEven with the presumably quick fix of changing the permissions on `libraries`, the very use of that folder means that two people cannot validate simultaneously on the same machine.\r\n\r\nCan we fix this?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/15387Unable to set testsuite verbosity to zero from command line2019-07-07T18:12:52ZlanttiUnable to set testsuite verbosity to zero from command lineSetting testsuite verbosity to zero from commandline using 'make test VERBOSE=0' does not work because runtests.py confuses the value 0 with value None. Solution: check explicitly for None instead of any value considered equal to False.
...Setting testsuite verbosity to zero from commandline using 'make test VERBOSE=0' does not work because runtests.py confuses the value 0 with value None. Solution: check explicitly for None instead of any value considered equal to False.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unable to set testsuite verbosity to zero from command line","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Setting testsuite verbosity to zero from commandline using 'make test VERBOSE=0' does not work because runtests.py confuses the value 0 with value None. Solution: check explicitly for None instead of any value considered equal to False.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1lanttilanttihttps://gitlab.haskell.org/ghc/ghc/-/issues/15062num009 is incredibly platform-sensitive2022-01-16T09:37:43ZBen Gamarinum009 is incredibly platform-sensitiveThe functions tested by `num009` are certainly worthwhile to test, but we really need to find a better way to test them. Currently the test seemingly fails in more places than it passes:
- Fails on Darwin (#2370)
- Fails on POWER8 (#136...The functions tested by `num009` are certainly worthwhile to test, but we really need to find a better way to test them. Currently the test seemingly fails in more places than it passes:
- Fails on Darwin (#2370)
- Fails on POWER8 (#13634)
- Fails on Win32 when in the `ghci` way (no ticket)
- Fails under i386 on CircleCI (e.g. https://circleci.com/gh/ghc/ghc/3666)
Perhaps we should instead test the output against the same evaluations performed by a C program. This would eliminate spurious failures due to platform or C library differences.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"num009 is incredibly platform-sensitive","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The functions tested by `num009` are certainly worthwhile to test, but we really need to find a better way to test them. Currently the test seemingly fails in more places than it passes:\r\n\r\n * Fails on Darwin (#2370)\r\n * Fails on POWER8 (#13634)\r\n * Fails on Win32 when in the `ghci` way (no ticket)\r\n * Fails under i386 on CircleCI (e.g. https://circleci.com/gh/ghc/ghc/3666)\r\n\r\nPerhaps we should instead test the output against the same evaluations performed by a C program. This would eliminate spurious failures due to platform or C library differences.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/12715T3994 is intermittently broken on Windows2019-07-07T18:25:26ZBen GamariT3994 is intermittently broken on WindowsThe `T3994` testcase sometimes appears to crash on Windows,
```
+++ ../../libraries/process/tests/T3994.run/T3994.run.stderr.normalised 2016-10-16 03:11:54.601205700 +0000
@@ -0,0 +1,2 @@
+ 1521 [main] sh 5272 child_copy: cygheap read...The `T3994` testcase sometimes appears to crash on Windows,
```
+++ ../../libraries/process/tests/T3994.run/T3994.run.stderr.normalised 2016-10-16 03:11:54.601205700 +0000
@@ -0,0 +1,2 @@
+ 1521 [main] sh 5272 child_copy: cygheap read copy failed, 0x1802FE408..0x180307A08, done 0, windows pid 5272, Win32 error 299
+ 7952 [main] sh 5272 C:/msys64/usr/bin/sh: *** fatal error in forked process - ccalloc would have returned NULL
```
This very well may be an msys issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx- |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T3994 is intermittently broken on Windows","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-"],"type":"Bug","description":"The `T3994` testcase sometimes appears to crash on Windows,\r\n{{{\r\n+++ ../../libraries/process/tests/T3994.run/T3994.run.stderr.normalised 2016-10-16 03:11:54.601205700 +0000\r\n@@ -0,0 +1,2 @@\r\n+ 1521 [main] sh 5272 child_copy: cygheap read copy failed, 0x1802FE408..0x180307A08, done 0, windows pid 5272, Win32 error 299\r\n+ 7952 [main] sh 5272 C:/msys64/usr/bin/sh: *** fatal error in forked process - ccalloc would have returned NULL\r\n\r\n}}}\r\nThis very well may be an msys issue.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/12669Add some weird Kmettian tests to the test suite2023-01-22T04:01:20ZDavid FeuerAdd some weird Kmettian tests to the test suite`reflection` does some funny business essentially coercing between `->` and `=>`. `constraints` has some code that's very sensitive to superclass cycle detection. And there's some other package (`structures`?) that coerces between `*` an...`reflection` does some funny business essentially coercing between `->` and `=>`. `constraints` has some code that's very sensitive to superclass cycle detection. And there's some other package (`structures`?) that coerces between `*` and `#` to stick raw `MutArr#` pointers into arrays. I believe Kmett also uses `unsafeCoerce# reallyUnsafePtrEquality#` to compare pointers of kind `#` to others (of possibly different types).
None of these things are anything like officially supported. However, breaking them could be expensive for the ecosystem. Dealing with breakage when someone discovers it months later can be very hard, so I think some of these things should probably be added to the GHC test suite. Failures shouldn't categorically prevent changes from being merged, but they would provide an early warning and get conversations started earlier.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add some weird Kmettian tests to the test suite","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"FeatureRequest","description":"`reflection` does some funny business essentially coercing between `->` and `=>`. `constraints` has some code that's very sensitive to superclass cycle detection. And there's some other package (`structures`?) that coerces between `*` and `#` to stick raw `MutArr#` pointers into arrays. I believe Kmett also uses `unsafeCoerce# reallyUnsafePtrEquality#` to compare pointers of kind `#` to others (of possibly different types).\r\n\r\nNone of these things are anything like officially supported. However, breaking them could be expensive for the ecosystem. Dealing with breakage when someone discovers it months later can be very hard, so I think some of these things should probably be added to the GHC test suite. Failures shouldn't categorically prevent changes from being merged, but they would provide an early warning and get conversations started earlier.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/16217check-api-annotations should check that an annotation does not precede its span2019-07-07T18:00:56ZAlan Zimmermancheck-api-annotations should check that an annotation does not precede its spanFor an API annotation to be useful, it must not occur before the span it is enclosed in.
So, for `check-api-annotation` output, a line such as
```
((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]),
```
should be flagged as an err...For an API annotation to be useful, it must not occur before the span it is enclosed in.
So, for `check-api-annotation` output, a line such as
```
((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]),
```
should be flagged as an error, as the `AnnOpenP` location of `3:21` precedes its enclosing span of `3:22-26`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"check-api-annotations should check that an annotation does not precede its span","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"For an API annotation to be useful, it must not occur before the span it is enclosed in.\r\n\r\nSo, for `check-api-annotation` output, a line such as\r\n\r\n{{{\r\n((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]),\r\n}}}\r\n\r\nshould be flagged as an error, as the `AnnOpenP` location of `3:21` precedes its enclosing span of `3:22-26`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15924Do not save performance test results if worktree is dirty2019-07-07T18:02:26ZdavideDo not save performance test results if worktree is dirtyThe test driver will automatically save performance results to git notes. Notes are attached to commits, but if the working tree is dirty, performance characteristics my be affected and the saved results will not be valid.
- Only save p...The test driver will automatically save performance results to git notes. Notes are attached to commits, but if the working tree is dirty, performance characteristics my be affected and the saved results will not be valid.
- Only save performance test results if work tree is dirty.
- Bonus: don't save to a git note if we have 0 results.
- Update wiki page.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Do not save performance test results if work tree is dirty","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["git","notes","performance","tests"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The test driver will automatically save performance results to git notes. Notes are attached to commits, but if the working tree is dirty, performance characteristics my be affected and the saved results will not be valid.\r\n\r\n* Only save performance test results if work tree is dirty.\r\n* Bonus: don't save to a git note if we have 0 results.\r\n* Update wiki page.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1davidedavidehttps://gitlab.haskell.org/ghc/ghc/-/issues/15856GhostScript not available for hp2ps tests2019-07-07T18:02:42Zjrp2014GhostScript not available for hp2ps testsWhen I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.
I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer...When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.
I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that).
The message "GhostScript not available for hp2ps tests" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated.
There are probably 2 ways forward:
- a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable
- figuring out why the python script fails to understand that a ghostscript is actually present and fixing that
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GhostScript not available for hp2ps tests","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["ghostscript","gs","hp2ps","testsuite"],"differentials":[],"test_case":"","architecture":"","cc":["Simonmar"],"type":"Bug","description":"When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`.\r\n\r\nI don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that).\r\n\r\nThe message \"GhostScript not available for hp2ps tests\" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated.\r\n\r\nThere are probably 2 ways forward:\r\n\r\n - a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable\r\n\r\n- figuring out why the python script fails to understand that a ghostscript is actually present and fixing that","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Krzysztof GogolewskiKrzysztof Gogolewskihttps://gitlab.haskell.org/ghc/ghc/-/issues/15363Do some cleaning up of the testsuite driver2019-07-07T18:12:59ZlanttiDo some cleaning up of the testsuite driverWhen trying to understand the GHC test suite I noticed some small improvements that I could do to it. This would probably work nicely as my first task on GHC:
Rewrite the timeout.hs in python, it is used for Windows runs but it doesn't ...When trying to understand the GHC test suite I noticed some small improvements that I could do to it. This would probably work nicely as my first task on GHC:
Rewrite the timeout.hs in python, it is used for Windows runs but it doesn't seem to do anything that would strictly need the Haskell libraries to be used and it is the only part of the test suite driver that is not written in python.
Or;
See if the timeout scripts could be eliminated altogether as the python subprocess module that we are using can now (since python 3.3) handle timeouts by itself and using the timeout scripts effectively doubles the number of processes we need to create for each test case. Notice that the timeout scripts do more than just generating the timeout.8.8.1lanttilanttihttps://gitlab.haskell.org/ghc/ghc/-/issues/15071:set usage in ghci tests breaks platform independence of output2019-07-07T18:14:24ZBen Gamari:set usage in ghci tests breaks platform independence of outputNumerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance:
```
--- "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024...Numerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance:
```
--- "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000
+++ "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.run.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000
@@ -7,7 +7,6 @@
GHCi-specific dynamic flag settings:
other dynamic, non-language, flag settings:
-fno-diagnostics-show-caret
- -fexternal-dynamic-refs
-fignore-optim-changes
-fignore-hpc-changes
-fno-ghci-history
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":set usage in ghci tests breaks platform independence of output","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Numerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance:\r\n{{{\r\n--- \"/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.stdout.normalised\"\t2018-04-19 18:35:50.927278200 +0000\r\n+++ \"/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.run.stdout.normalised\"\t2018-04-19 18:35:50.927278200 +0000\r\n@@ -7,7 +7,6 @@\r\n GHCi-specific dynamic flag settings:\r\n other dynamic, non-language, flag settings:\r\n -fno-diagnostics-show-caret\r\n- -fexternal-dynamic-refs\r\n -fignore-optim-changes\r\n -fignore-hpc-changes\r\n -fno-ghci-history\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/15059ghcpkg05 fails2019-07-07T18:14:29ZBen Gamarighcpkg05 failsSeveral people have noted that `ghcpkg05` seems to fail in some environments with (taken from CircleCI, https://circleci.com/gh/ghc/ghc/3654),
```
--- ./cabal/ghcpkg05.run/ghcpkg05.stderr.normalised 2018-04-19 14:14:29.043902308 +0000
+...Several people have noted that `ghcpkg05` seems to fail in some environments with (taken from CircleCI, https://circleci.com/gh/ghc/ghc/3654),
```
--- ./cabal/ghcpkg05.run/ghcpkg05.stderr.normalised 2018-04-19 14:14:29.043902308 +0000
+++ ./cabal/ghcpkg05.run/ghcpkg05.run.stderr.normalised 2018-04-19 14:14:29.043902308 +0000
@@ -10,6 +10,13 @@
cannot find any of ["C/D.hi","C/D.p_hi","C/D.dyn_hi"]
cannot find any of ["C/E.hi","C/E.p_hi","C/E.dyn_hi"]
cannot find any of ["libtestpkg-2.0-XXX.a","libtestpkg-2.0-XXX.p_a","libtestpkg-2.0-XXX-ghc<VERSION>.so","libtestpkg-2.0-XXX-ghc<VERSION>.dylib","testpkg-2.0-XXX-ghc<VERSION>.dll"] on library path
+Warning: include-dirs: /home/ghc/project/compiler/stage2/build/utils doesn't exist or isn't a directory
+Warning: include-dirs: /home/ghc/project/compiler/stage2/build/../rts/dist/build doesn't exist or isn't a directory
+Warning: include-dirs: /home/ghc/project/compiler/stage2/build/stage2 doesn't exist or isn't a directory
+Warning: include-dirs: /home/ghc/project/libraries/haskeline/dist-install/build/includes doesn't exist or isn't a directory
+Warning: include-dirs: /home/ghc/project/libraries/text/dist-install/build/include doesn't exist or isn't a directory
+Warning: include-dirs: /home/ghc/project/libraries/containers/dist-install/build/include doesn't exist or isn't a directory
+Warning: include-dirs: /home/ghc/project/libraries/bytestring/dist-install/build/include doesn't exist or isn't a directory
The following packages are broken, either because they have a problem
listed above, or because they depend on a broken package.
*** unexpected failure for ghcpkg05(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghcpkg05 fails","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Several people have noted that `ghcpkg05` seems to fail in some environments with (taken from CircleCI, https://circleci.com/gh/ghc/ghc/3654),\r\n{{{\r\n--- ./cabal/ghcpkg05.run/ghcpkg05.stderr.normalised\t2018-04-19 14:14:29.043902308 +0000\r\n+++ ./cabal/ghcpkg05.run/ghcpkg05.run.stderr.normalised\t2018-04-19 14:14:29.043902308 +0000\r\n@@ -10,6 +10,13 @@\r\n cannot find any of [\"C/D.hi\",\"C/D.p_hi\",\"C/D.dyn_hi\"]\r\n cannot find any of [\"C/E.hi\",\"C/E.p_hi\",\"C/E.dyn_hi\"]\r\n cannot find any of [\"libtestpkg-2.0-XXX.a\",\"libtestpkg-2.0-XXX.p_a\",\"libtestpkg-2.0-XXX-ghc<VERSION>.so\",\"libtestpkg-2.0-XXX-ghc<VERSION>.dylib\",\"testpkg-2.0-XXX-ghc<VERSION>.dll\"] on library path\r\n+Warning: include-dirs: /home/ghc/project/compiler/stage2/build/utils doesn't exist or isn't a directory\r\n+Warning: include-dirs: /home/ghc/project/compiler/stage2/build/../rts/dist/build doesn't exist or isn't a directory\r\n+Warning: include-dirs: /home/ghc/project/compiler/stage2/build/stage2 doesn't exist or isn't a directory\r\n+Warning: include-dirs: /home/ghc/project/libraries/haskeline/dist-install/build/includes doesn't exist or isn't a directory\r\n+Warning: include-dirs: /home/ghc/project/libraries/text/dist-install/build/include doesn't exist or isn't a directory\r\n+Warning: include-dirs: /home/ghc/project/libraries/containers/dist-install/build/include doesn't exist or isn't a directory\r\n+Warning: include-dirs: /home/ghc/project/libraries/bytestring/dist-install/build/include doesn't exist or isn't a directory\r\n \r\n The following packages are broken, either because they have a problem\r\n listed above, or because they depend on a broken package.\r\n*** unexpected failure for ghcpkg05(normal)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/14534Split T12971 into its own Makefile2019-07-07T18:16:37ZDavid FeuerSplit T12971 into its own Makefile`testsuite/tests/driver/Makefile` includes the `T12971` target. This (intentionally) has non-ASCII characters in it. As a result, any change to that makefile will trigger a lint error. We should give that test its own makefile to isolate...`testsuite/tests/driver/Makefile` includes the `T12971` target. This (intentionally) has non-ASCII characters in it. As a result, any change to that makefile will trigger a lint error. We should give that test its own makefile to isolate it a bit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Split T12971 into its own Makefile","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"`testsuite/tests/driver/Makefile` includes the `T12971` target. This (intentionally) has non-ASCII characters in it. As a result, any change to that makefile will trigger a lint error. We should give that test its own makefile to isolate it a bit.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/17459T17414 breaks if TMP is on a small tmpfs2019-11-21T18:08:15ZBen GamariT17414 breaks if TMP is on a small tmpfs`T17414` tries to write a large (multi-gigabyte) file. However, this breaks if `TMP` (and therefore the test run directory) is on a small `tmpfs`:
```
Traceback (most recent call last):
File "/mnt/work/ghc/ghc-compare-3/testsuite/drive...`T17414` tries to write a large (multi-gigabyte) file. However, this breaks if `TMP` (and therefore the test run directory) is on a small `tmpfs`:
```
Traceback (most recent call last):
File "/mnt/work/ghc/ghc-compare-3/testsuite/driver/testlib.py", line 973, in test_common_work
do_test(name, way, func, args, files)
File "/mnt/work/ghc/ghc-compare-3/testsuite/driver/testlib.py", line 1071, in do_test
result = func(*[name,way] + args)
File "/mnt/work/ghc/ghc-compare-3/testsuite/driver/testlib.py", line 1352, in compile_and_run
return compile_and_run__( name, way, None, [], extra_hc_opts)
File "/mnt/work/ghc/ghc-compare-3/testsuite/driver/testlib.py", line 1349, in compile_and_run__
return simple_run( name, way, cmd, getTestOpts().extra_run_opts )
File "/mnt/work/ghc/ghc-compare-3/testsuite/driver/testlib.py", line 1591, in simple_run
exit_code = runCmd(cmd, stdin_arg, stdout_arg, stderr_arg, opts.run_timeout_multiplier)
File "/mnt/work/ghc/ghc-compare-3/testsuite/driver/testlib.py", line 2263, in runCmd
stderr.write_bytes(stderr_buffer)
File "/nix/store/4c4ajgdnhlqk994hilagk5cgv7vw9yzg-python3-3.7.3/lib/python3.7/pathlib.py", line 1209, in write_bytes
return f.write(view)
OSError: [Errno 28] No space left on device
```8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17235Job Failed #1614272019-09-24T22:59:24ZGabor GreifJob Failed #161427I have never seen T16916 failing before, so maybe this is a flakey test with a very small probability? I think better report it.
Job [#161427](https://gitlab.haskell.org/ghc/ghc/-/jobs/161427) failed for c9349144f15697f15d356c96eff62636...I have never seen T16916 failing before, so maybe this is a flakey test with a very small probability? I think better report it.
Job [#161427](https://gitlab.haskell.org/ghc/ghc/-/jobs/161427) failed for c9349144f15697f15d356c96eff62636566f9c21:8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16951TcCoercibleFail times out in a DEBUG compiler (again)2019-07-23T18:23:34ZRichard Eisenbergrae@richarde.devTcCoercibleFail times out in a DEBUG compiler (again)The test `typecheck/should_fail/TcCoercibleFail` is timing out on my machine (a Mac) on a DEBUG compiler.
Curiously, the `all.T` says
```
# TcCoercibleFail times out with the compiler is compiled with -DDEBUG.
# This is expected (see ...The test `typecheck/should_fail/TcCoercibleFail` is timing out on my machine (a Mac) on a DEBUG compiler.
Curiously, the `all.T` says
```
# TcCoercibleFail times out with the compiler is compiled with -DDEBUG.
# This is expected (see comment in source file).
test('TcCoercibleFail', [when(compiler_debugged(), skip)], compile_fail, [''])
```
So it seems the `when(compiler_debugged(), skip)` bit isn't doing its job.
Note that the long running time itself was #11518, but I really think the current bug I'm reporting is about the testsuite scripts, not about the type-checker (or that ticket, really).8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16855T16608 tests fail on Darwin2019-06-27T03:10:01ZBen GamariT16608 tests fail on Darwin```patch
--- driver/T16608/T16608_2.run/T16608_2.stdout.normalised 2019-06-21 23:15:43.000000000 -0700
+++ driver/T16608/T16608_2.run/T16608_2.run.stdout.normalised 2019-06-21 23:15:43.000000000 -0700
@@ -2,6 +2,4 @@
[2 of 2] Compiling ...```patch
--- driver/T16608/T16608_2.run/T16608_2.stdout.normalised 2019-06-21 23:15:43.000000000 -0700
+++ driver/T16608/T16608_2.run/T16608_2.run.stdout.normalised 2019-06-21 23:15:43.000000000 -0700
@@ -2,6 +2,4 @@
[2 of 2] Compiling Main ( T16608_2.hs, T16608_2.o )
Linking T16608_2 ...
41
-[1 of 2] Compiling MyInteger ( MyInteger.hs, MyInteger.o )
-Linking T16608_2 ...
-42
+41
```8.10.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16853ghci058 failure on Windows2019-06-24T21:53:05ZBen Gamarighci058 failure on WindowsI just saw the following failure of `ghci058` on Windows:
```patch
--- ghci/scripts/ghci058.run/ghci058.stdout.normalised 2019-06-21 22:58:17.923422700 +0000
+++ ghci/scripts/ghci058.run/ghci058.run.stdout.normalised 2019-06-21 22:58:17....I just saw the following failure of `ghci058` on Windows:
```patch
--- ghci/scripts/ghci058.run/ghci058.stdout.normalised 2019-06-21 22:58:17.923422700 +0000
+++ ghci/scripts/ghci058.run/ghci058.run.stdout.normalised 2019-06-21 22:58:17.930310400 +0000
@@ -1,4 +1,4 @@
Ok, one module loaded.
'a'
Ok, one module loaded.
-'b'
+'a'
```8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16818Performance metrics don't distinguish between compile-time and runtime metrics2020-06-30T14:31:10ZBen GamariPerformance metrics don't distinguish between compile-time and runtime metricsWhile purusing the testsuite performance metrics output while looking at !1063 I noticed that the performance metrics output does not give any indication whether, e.g., the `bytes allocated` metric is measuring the allocations of the com...While purusing the testsuite performance metrics output while looking at !1063 I noticed that the performance metrics output does not give any indication whether, e.g., the `bytes allocated` metric is measuring the allocations of the compiler or the compiled program. This may come to bite us if we want to do more thorough performance measurements (e.g. tracking compiler allocations of all testcases).
@DavidEichmann, what do you think we should do about this? My suggestion would be to change the names of the compiler metrics and rename the existing performance notes refs to prevent confusion.8.10.1David EichmannDavid Eichmannhttps://gitlab.haskell.org/ghc/ghc/-/issues/16814executeFile001 is fragile under CI2019-06-15T19:15:07ZBen GamariexecuteFile001 is fragile under CI`executeFile001` seems to be fragile in the `threaded2` way on CI under various Linux jobs. The failure is always of the form:
```
Wrong exit code for executeFile001(threaded2)(expected 0 , actual 1 )
Stderr ( executeFile001 ):
executeFi...`executeFile001` seems to be fragile in the `threaded2` way on CI under various Linux jobs. The failure is always of the form:
```
Wrong exit code for executeFile001(threaded2)(expected 0 , actual 1 )
Stderr ( executeFile001 ):
executeFile001: failed to create OS thread: Resource temporarily unavailable
*** unexpected failure for executeFile001(threaded2)
```
My feeling is that this happens in no more than 10% of CI jobs.
The symptoms match what is described [here](https://unix.stackexchange.com/questions/253903/creating-threads-fails-with-resource-temporarily-unavailable-with-4-3-kernel).8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16798`enum0[123]` tests are not portable2019-06-13T16:08:35ZBen Gamari`enum0[123]` tests are not portableIn particular the clever but slightly horrifying `enum_processor.bat` does not work on musl since it lacks a hash-bang.In particular the clever but slightly horrifying `enum_processor.bat` does not work on musl since it lacks a hash-bang.8.10.1