GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:03:23Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15699Run sanity checker in more testsuite runs2019-07-07T18:03:23ZBen GamariRun sanity checker in more testsuite runsEvery testsuite run should run at least a subset of tests with the sanity checker enabled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- ...Every testsuite run should run at least a subset of tests with the sanity checker enabled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Run sanity checker in more testsuite runs","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Every testsuite run should run at least a subset of tests with the sanity checker enabled.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15582Phabricator shows "drafts" by default2019-07-07T18:04:02ZKrzysztof GogolewskiPhabricator shows "drafts" by defaultBy default, going to https://phabricator.haskell.org/differential/ shows "Drafts". This category isn't very useful. Is it possible to create a query for "All open" (Statuses: "Any Open Status") and make it the default?
I've done this al...By default, going to https://phabricator.haskell.org/differential/ shows "Drafts". This category isn't very useful. Is it possible to create a query for "All open" (Statuses: "Any Open Status") and make it the default?
I've done this already on my account, but I think it makes sense to do this globally.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Phabricator shows \"drafts\" by default","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"By default, going to https://phabricator.haskell.org/differential/ shows \"Drafts\". This category isn't very useful. Is it possible to create a query for \"All open\" (Statuses: \"Any Open Status\") and make it the default?\r\n\r\nI've done this already on my account, but I think it makes sense to do this globally.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15255overflow1 breaks on i3862019-07-07T18:13:36ZBen Gamarioverflow1 breaks on i386The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:
```
=====> overflow1(normal) 4082 of 6414 [0, 3, 0]
Wrong exit code for overflow1(normal)(expected 251 , actual 0 )
*** unexpected failure for overflow1(n...The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:
```
=====> overflow1(normal) 4082 of 6414 [0, 3, 0]
Wrong exit code for overflow1(normal)(expected 251 , actual 0 )
*** unexpected failure for overflow1(normal)
```
Need to work out what is going on here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"overflow1 breaks on i386","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The i386 CircleCI target is showing a mysterious failure of the `overflow1` test:\r\n{{{\r\n=====> overflow1(normal) 4082 of 6414 [0, 3, 0]\r\nWrong exit code for overflow1(normal)(expected 251 , actual 0 )\r\n*** unexpected failure for overflow1(normal)\r\n}}}\r\n\r\nNeed to work out what is going on here.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15230unix tests fail under CircleCI's fedora environment2021-03-12T00:39:41ZBen Gamariunix tests fail under CircleCI's fedora environmentIt's a bit unclear what is going on here:
```
=====> getGroupEntryForName(normal) 6377 of 6403 [0, 0, 0]
Actual stdout output differs from expected:
--- ../../libraries/unix/tests/user001.run/user001.stdout.normalised 2018-06-05 15:18:3...It's a bit unclear what is going on here:
```
=====> getGroupEntryForName(normal) 6377 of 6403 [0, 0, 0]
Actual stdout output differs from expected:
--- ../../libraries/unix/tests/user001.run/user001.stdout.normalised 2018-06-05 15:18:37.243934191 +0000
+++ ../../libraries/unix/tests/user001.run/user001.run.stdout.normalised 2018-06-05 15:18:37.243934191 +0000
@@ -6,6 +6,6 @@
getEffectiveUserName: OK
getGroupEntryForID: OK
getGroupEntryForName: OK
-getAllGroupEntries: OK
+getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory)
getUserEntryForID: OK
getAllUserEntries: OK
*** unexpected failure for user001(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unix tests fail under CircleCI's fedora environment","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It's a bit unclear what is going on here:\r\n\r\n{{{\r\n=====> getGroupEntryForName(normal) 6377 of 6403 [0, 0, 0]\r\nActual stdout output differs from expected:\r\n--- ../../libraries/unix/tests/user001.run/user001.stdout.normalised\t2018-06-05 15:18:37.243934191 +0000\r\n+++ ../../libraries/unix/tests/user001.run/user001.run.stdout.normalised\t2018-06-05 15:18:37.243934191 +0000\r\n@@ -6,6 +6,6 @@\r\n getEffectiveUserName: OK\r\n getGroupEntryForID: OK\r\n getGroupEntryForName: OK\r\n-getAllGroupEntries: OK\r\n+getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory)\r\n getUserEntryForID: OK\r\n getAllUserEntries: OK\r\n*** unexpected failure for user001(normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15093Testsuite should output JUnit XML for better CircleCI support2019-07-07T18:14:17ZMatthew PickeringTestsuite should output JUnit XML for better CircleCI supportAt the moment when builds are run on CircleCI, failures are not reported in any special way. This means you have to download the build log to see the bottom of the testing phase as it is too long to see in the browser.
Instead, you can ...At the moment when builds are run on CircleCI, failures are not reported in any special way. This means you have to download the build log to see the bottom of the testing phase as it is too long to see in the browser.
Instead, you can output the test results as JUnit XML which then CircleCI can slurp up and present nicely. https://circleci.com/docs/2.0/configuration-reference/\#store_test_results
There is a python library which makes it easy to generate this output. https://github.com/kyrus/python-junit-xml
Even better, an actual python testing library could be used which could automatically output this information.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite should output JUnit XML for better CircleCI support","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["CI"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"At the moment when builds are run on CircleCI, failures are not reported in any special way. This means you have to download the build log to see the bottom of the testing phase as it is too long to see in the browser.\r\n\r\nInstead, you can output the test results as JUnit XML which then CircleCI can slurp up and present nicely. https://circleci.com/docs/2.0/configuration-reference/#store_test_results\r\n\r\nThere is a python library which makes it easy to generate this output. https://github.com/kyrus/python-junit-xml\r\n\r\nEven better, an actual python testing library could be used which could automatically output this information.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14706T11489 fails if run as root2019-07-07T18:15:56ZBen GamariT11489 fails if run as rootThe testcase `T11489` tests for #11489 by creating a `.prof` file, removing its write bit, and trying to run a program with profiling enabled. Usually the program would fail with an error message as the RTS can't open the `.prof` file fo...The testcase `T11489` tests for #11489 by creating a `.prof` file, removing its write bit, and trying to run a program with profiling enabled. Usually the program would fail with an error message as the RTS can't open the `.prof` file for writing. However, when run as `root` the test succeeds.
"What madman would compile GHC as `root`?" you ask? Well, CircleCI runs builds as `root` by default. It seems like running builds under Docker is one way around this, although this seems like a pretty large hammer just to eliminate a single test failure.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T11489 fails if run as root","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The testcase `T11489` tests for #11489 by creating a `.prof` file, removing its write bit, and trying to run a program with profiling enabled. Usually the program would fail with an error message as the RTS can't open the `.prof` file for writing. However, when run as `root` the test succeeds.\r\n\r\n\"What madman would compile GHC as `root`?\" you ask? Well, CircleCI runs builds as `root` by default. It seems like running builds under Docker is one way around this, although this seems like a pretty large hammer just to eliminate a single test failure.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1mrkkrpmrkkrphttps://gitlab.haskell.org/ghc/ghc/-/issues/14600Work out why Hadrian builds routinely fail2019-07-07T18:16:21ZBen GamariWork out why Hadrian builds routinely failCurrently Hadrian builds inexplicably and non-deterministically fail on CircleCI. They fail with,
```
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_l.a
| Copy file (untracked): _build/stage...Currently Hadrian builds inexplicably and non-deterministically fail on CircleCI. They fail with,
```
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_l.a
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_debug.a
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr.a
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_debug.a
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_l.a
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_p.a
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffidebug_-ghc8.5.20171218.so
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_-ghc8.5.20171218.so
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_debug_-ghc8.5.20171218.so
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffil_-ghc8.5.20171218.so
| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_l_-ghc8.5.20171218.so
| Successfully built custom library 'libffi'
Too long with no output (exceeded 10m0s)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Work out why Hadrian builds routinely fail","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently Hadrian builds inexplicably and non-deterministically fail on CircleCI. They fail with,\r\n{{{\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_l.a\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_debug.a\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr.a\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_debug.a\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_l.a\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_p.a\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffidebug_-ghc8.5.20171218.so\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_-ghc8.5.20171218.so\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_debug_-ghc8.5.20171218.so\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffil_-ghc8.5.20171218.so\r\n| Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_l_-ghc8.5.20171218.so\r\n| Successfully built custom library 'libffi'\r\nToo long with no output (exceeded 10m0s)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14470CircleCI: Detect number of processors2019-07-07T18:16:54ZBen GamariCircleCI: Detect number of processorsCurrently we hard-code the thread count to 8, which is what the machines which jobs from the `ghc/ghc` repository run on. However, such machines are not available to owners of `ghc` forks (unless they specifically request a resource limi...Currently we hard-code the thread count to 8, which is what the machines which jobs from the `ghc/ghc` repository run on. However, such machines are not available to owners of `ghc` forks (unless they specifically request a resource limit bump from CircleCI).
We should automatically detect the CPU count to ensure that CI on smaller instances will not fail due to oversubscription.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"CircleCI: Detect number of processors","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Currently we hard-code the thread count to 8, which is what the machines which jobs from the `ghc/ghc` repository run on. However, such machines are not available to owners of `ghc` forks (unless they specifically request a resource limit bump from CircleCI).\r\n\r\nWe should automatically detect the CPU count to ensure that CI on smaller instances will not fail due to oversubscription.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14416CI with CircleCI2019-07-07T18:17:07ZManuel M T ChakravartyCI with CircleCIMerging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- |...Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"CI with CircleCI","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13240Make it easier to find builds we may want to cancel2019-07-07T18:22:58ZDavid FeuerMake it easier to find builds we may want to cancelI'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples:
1. Someone pushed several versions of a single differential, and i...I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples:
1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest.
1. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific.
1. Only documentation files have changed. Building these on one platform should be sufficient.
1. A differential was closed by a commit. Only the most recent build will be useful, if that.
It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Trac & Git |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make it easier to find builds we may want to cancel","status":"New","operating_system":"","component":"Trac & Git","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"mpickering"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples:\r\n\r\n1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest.\r\n\r\n2. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific.\r\n\r\n3. Only documentation files have changed. Building these on one platform should be sufficient.\r\n\r\n4. A differential was closed by a commit. Only the most recent build will be useful, if that.\r\n\r\nIt would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/13205Run `validate --slow` during CI at least sometimes.2019-07-07T18:23:11ZdobenourRun `validate --slow` during CI at least sometimes.We really should run `validate --slow` at times. It would catch #13204.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 ...We really should run `validate --slow` at times. It would catch #13204.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Run `validate --slow` during CI at least sometimes.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We really should run `validate --slow` at times. It would catch #13204.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamari