GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:44:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/84717.8.1 release notes typo2019-07-07T18:44:55Zerrge7.8.1 release notes typo1. 8.1 says that the time package now supports annotation. That doesn't make sense, that must be the template-haskell package. :)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------------...1. 8.1 says that the time package now supports annotation. That doesn't make sense, that must be the template-haskell package. :)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"7.8.1 release notes typo","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"7.8.1 says that the time package now supports annotation. That doesn't make sense, that must be the template-haskell package. :)","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8434dynflag dependency addition in TcRnDriver is not needed anymore2019-07-07T18:45:05Zerrgedynflag dependency addition in TcRnDriver is not needed anymoreThe removed parts of the `tcRnImports` function in the attached patch says that there is a check in `LoadIface.loadInterface` and this is why it's needed to add the plugin dependencies to the EPS.
But actually \[\[GhcFile(compiler/iface...The removed parts of the `tcRnImports` function in the attached patch says that there is a check in `LoadIface.loadInterface` and this is why it's needed to add the plugin dependencies to the EPS.
But actually \[\[GhcFile(compiler/iface/LoadIface.lhs\#L227)\]\] says that the check is no longer there.7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8433forkProcess masks async exceptions inside the child process2019-07-07T18:45:05ZjoeyhforkProcess masks async exceptions inside the child processFrankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.
FWIW, I have lo...Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.
FWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"forkProcess masks async exceptions inside the child process","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.\r\n\r\nFWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8432clarify throwTo documentation2019-07-07T18:45:05ZBertram Felgenhauerclarify throwTo documentationAs discussed in the thread http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23889
the documentation of `GHC.Conc.throwTo` is not 100% clear on the provided atomicity guarantees.
In http://article.gmane.org/gmane.comp.lang.ha...As discussed in the thread http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23889
the documentation of `GHC.Conc.throwTo` is not 100% clear on the provided atomicity guarantees.
In http://article.gmane.org/gmane.comp.lang.haskell.libraries/20218 I proposed a patch for said documentation but it seems to have slipped through the cracks. Can somebody please have a look and - hopefully - apply it?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"clarify throwTo documentation","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As discussed in the thread http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23889\r\nthe documentation of {{{GHC.Conc.throwTo}}} is not 100% clear on the provided atomicity guarantees.\r\n\r\nIn http://article.gmane.org/gmane.comp.lang.haskell.libraries/20218 I proposed a patch for said documentation but it seems to have slipped through the cracks. Can somebody please have a look and - hopefully - apply it?","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8418[patch] comments outdated2019-07-07T18:45:09Zerrge[patch] comments outdatedDuring working on GHC, I found these outdated comments and function names.
The `ForPlugins` renaming in \[\[GhcFile(compiler/main/DynamicLoading.hs)\]\] is motivated by the fact that change \[57d67983\] crippled the function in a way th...During working on GHC, I found these outdated comments and function names.
The `ForPlugins` renaming in \[\[GhcFile(compiler/main/DynamicLoading.hs)\]\] is motivated by the fact that change \[57d67983\] crippled the function in a way that now it can only be used while handling Plugins. Therefore the name should warn the programmer to this fact.
The hptInstances comment has also been outdated, when someone needed to add the `ModuleName -> Bool` predicate to use this same function for handling ghc and ghci with shared code.
The attached patch is trivial renames/comments.7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8416GHC.Generics needs more documentation2019-07-07T18:45:09ZtibbeGHC.Generics needs more documentationRecently I tried to used `GHC.Generics` "in anger" for the first time, to fix some code in hashable that wasn't originally written by me. After a while I just gave up (and the generics support in hashable is now somewhat broken). The doc...Recently I tried to used `GHC.Generics` "in anger" for the first time, to fix some code in hashable that wasn't originally written by me. After a while I just gave up (and the generics support in hashable is now somewhat broken). The documentation for `GHC.Generics` is too incomprehensible for mere mortals. In particular, I find the documentation for `M1` and `K1` not very helpful.
The documentation needs examples, more in-depth explanations of what each of the data types/constructors is used for, and finally an explanation of the up to 4 type parameters!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Generics needs more documentation","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Recently I tried to used `GHC.Generics` \"in anger\" for the first time, to fix some code in hashable that wasn't originally written by me. After a while I just gave up (and the generics support in hashable is now somewhat broken). The documentation for `GHC.Generics` is too incomprehensible for mere mortals. In particular, I find the documentation for `M1` and `K1` not very helpful.\r\n\r\nThe documentation needs examples, more in-depth explanations of what each of the data types/constructors is used for, and finally an explanation of the up to 4 type parameters!","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8409nofib-analyse: compile allocations2019-07-07T18:45:11Zlerouxnofib-analyse: compile allocationsIn response to [ticket:8173\#comment:75651](https://gitlab.haskell.org//ghc/ghc/issues/8173#note_75651):
> Did you look at the amount of heap the compiler allocated? It's easily discoverable (eg use +RTS -s, and it's in the nofib logs t...In response to [ticket:8173\#comment:75651](https://gitlab.haskell.org//ghc/ghc/issues/8173#note_75651):
> Did you look at the amount of heap the compiler allocated? It's easily discoverable (eg use +RTS -s, and it's in the nofib logs too, though I don't think nofib-analyse looks for it. (You could fix nofib-analyse so that it does.)
Teach nofib to include allocation info (from module compilation time).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | leroux@fezrev.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"nofib-analyse","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["leroux@fezrev.com"],"type":"FeatureRequest","description":"In response to comment:13:ticket:8173:\r\n> Did you look at the amount of heap the compiler allocated? It's easily discoverable (eg use +RTS -s, and it's in the nofib logs too, though I don't think nofib-analyse looks for it. (You could fix nofib-analyse so that it does.)\r\n\r\nTeach nofib to include allocation info (from module compilation time).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1lerouxlerouxhttps://gitlab.haskell.org/ghc/ghc/-/issues/8397reify annotations in TH2019-07-07T18:45:13Zerrgereify annotations in THFor the use-case detailed in #7867, this patch adds annotation reification to TH.
This may be useful as a simpler approach for other cases too, where the whole power GHC API is not needed.
<details><summary>Trac metadata</summary>
| T...For the use-case detailed in #7867, this patch adds annotation reification to TH.
This may be useful as a simpler approach for other cases too, where the whole power GHC API is not needed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| 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":"reify annotations in TH","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For the use-case detailed in #7867, this patch adds annotation reification to TH.\r\n\r\nThis may be useful as a simpler approach for other cases too, where the whole power GHC API is not needed.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8352System function setitimer not detected in library process2019-07-07T18:45:25ZPeter Trommlerptrommler@acm.orgSystem function setitimer not detected in library processDue to a spurious comma in configure.ac setitimer is not detected.
I will attach a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Versio...Due to a spurious comma in configure.ac setitimer is not detected.
I will attach a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System function setitimer not detected in library process","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Due to a spurious comma in configure.ac setitimer is not detected.\r\n\r\nI will attach a patch.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8350shm_open and shm_unlink not detected on openSUSE Linux2019-07-07T18:45:26ZPeter Trommlerptrommler@acm.orgshm_open and shm_unlink not detected on openSUSE LinuxThe test in libraries/unix/configure fails to detect shm_\* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_\* function.
Note: The openSUS...The test in libraries/unix/configure fails to detect shm_\* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_\* function.
Note: The openSUSE linker sets --as-needed by default and hence the order of linker options does matter.
The attached patch fixes the issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"shm_open and shm_unlink not detected on openSUSE Linux","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The test in libraries/unix/configure fails to detect shm_* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_* function.\r\n\r\nNote: The openSUSE linker sets --as-needed by default and hence the order of linker options does matter.\r\n\r\nThe attached patch fixes the issue.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8349Extra space in CFLAGS for libffi includes2019-07-07T18:45:26ZPeter Trommlerptrommler@acm.orgExtra space in CFLAGS for libffi includesCompiling with system libffi include file in a non-standard location
fails due to a extra space in configure.ac.
Gentoo has the following "fix" in its ebuild:
```
sed -e 's@LIBFFI_CFLAGS="-I $withval"@LIBFFI_CFLAGS="-I$withval"@' \
...Compiling with system libffi include file in a non-standard location
fails due to a extra space in configure.ac.
Gentoo has the following "fix" in its ebuild:
```
sed -e 's@LIBFFI_CFLAGS="-I $withval"@LIBFFI_CFLAGS="-I$withval"@' \
-i "${S}/configure.ac" \
|| die "Could not remove space after -I from LIBFFI_CFLAGS in configure.ac and configure"
```
I attached a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Extra space in CFLAGS for libffi includes","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling with system libffi include file in a non-standard location\r\nfails due to a extra space in configure.ac.\r\n\r\nGentoo has the following \"fix\" in its ebuild:\r\n\r\n{{{\r\nsed -e 's@LIBFFI_CFLAGS=\"-I $withval\"@LIBFFI_CFLAGS=\"-I$withval\"@' \\\r\n -i \"${S}/configure.ac\" \\\r\n || die \"Could not remove space after -I from LIBFFI_CFLAGS in configure.ac and configure\"\r\n}}}\r\n\r\nI attached a patch.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8340support for generating annotations from TH2019-07-07T18:45:28Zerrgesupport for generating annotations from THThis patch adds support for template haskell generation of annotations. This is currently only possible directly via ```{-\# ANN function "whatever annotation \#-}```.
The attached patch makes it possible to do the same from TH.
Module...This patch adds support for template haskell generation of annotations. This is currently only possible directly via ```{-\# ANN function "whatever annotation \#-}```.
The attached patch makes it possible to do the same from TH.
Module and type annotations are supported too.
This is part of a larger effort to make it possible to cross-module communicate between template haskell runs. See #7867 for a longer discussion.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"support for generating annotations from TH","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This patch adds support for template haskell generation of annotations. This is currently only possible directly via ```{-# ANN function \"whatever annotation #-}```.\r\n\r\nThe attached patch makes it possible to do the same from TH.\r\n\r\nModule and type annotations are supported too.\r\n\r\nThis is part of a larger effort to make it possible to cross-module communicate between template haskell runs. See #7867 for a longer discussion.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8337make it possible for the user to force orphanness via a module-level annotation2019-07-07T18:45:29Zerrgemake it possible for the user to force orphanness via a module-level annotationA module is marked orphan currently only in the case when we detect orphan instances, rules, type families or vectorised stuff.
In the use-case of #7867, the user will need a way to manage orphanness more directly.
When she creates an ...A module is marked orphan currently only in the case when we detect orphan instances, rules, type families or vectorised stuff.
In the use-case of #7867, the user will need a way to manage orphanness more directly.
When she creates an annotation (with TH or by hand), it is written to the interface file. When another file directly imports this file, it is read, everything is right. But only orphan modules are searched for transitively. So in the case of command line flags (HFlags library), where we want to transitively read all the annotations (containing info about cmdline flags) in all the imported and grandchild imported modules, we have to mark the originator modules as orphan.
This patch adds support for a special module level annotation that forces this module to be orphan.
This is the first, meaningful, but still small part of a larger work to implement #7867.
The next part will be TH support to generate annotations (not only) like this.
I'd like to make this two part of 7.8.1, if still possible; because this already makes messaging possible through adhoc datatypes+instances.
After that (probably for 7.10) we only have to make it possible to read (module) annotations back in the Q monad to have a clean solution. The laborious part of that is making module reifyable at all.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| 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":"make it possible for the user to for orphanness of an annotation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A module is marked orphan currently only in the case when we detect orphan instances, rules, type families or vectorised stuff.\r\n\r\nIn the use-case of #7867, the user will need a way to manage orphanness more directly.\r\n\r\nWhen she creates an annotation (with TH or by hand), it is written to the interface file. When another file directly imports this file, it is read, everything is right. But only orphan modules are searched for transitively. So in the case of command line flags (HFlags library), where we want to transitively read all the annotations (containing info about cmdline flags) in all the imported and grandchild imported modules, we have to mark the originator modules as orphan.\r\n\r\nThis patch adds support for a special module level annotation that forces this module to be orphan.\r\n\r\nThis is the first, meaningful, but still small part of a larger work to implement #7867.\r\n\r\nThe next part will be TH support to generate annotations (not only) like this.\r\n\r\nI'd like to make this two part of 7.8.1, if still possible; because this already makes messaging possible through adhoc datatypes+instances.\r\n\r\nAfter that (probably for 7.10) we only have to make it possible to read (module) annotations back in the Q monad to have a clean solution. The laborious part of that is making module reifyable at all. ","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8307iOS patch: fix hangs in threaded runtime2019-07-07T18:45:37ZlukexiiOS patch: fix hangs in threaded runtimeExtends two darwin_HOST_OS cases in libraries/base/GHC/Event/Manager.hs to cover iOS as well. This fixes hangs occurring on iOS with the threaded runtime.
<details><summary>Trac metadata</summary>
| Trac field | Value ...Extends two darwin_HOST_OS cases in libraries/base/GHC/Event/Manager.hs to cover iOS as well. This fixes hangs occurring on iOS with the threaded runtime.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"iOS patch: fix hangs in threaded runtime","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["thoughtpolice"],"type":"Bug","description":"Extends two darwin_HOST_OS cases in libraries/base/GHC/Event/Manager.hs to cover iOS as well. This fixes hangs occurring on iOS with the threaded runtime.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8302Add 'bool' to Data.Bool2019-07-07T18:45:39ZOllie CharlesAdd 'bool' to Data.BoolAs mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------...As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add 'bool' to Data.Bool","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8257System.Mem: Expose performMinorGC2019-07-07T18:45:51ZNiklas Hambüchenmail@nh2.meSystem.Mem: Expose performMinorGCWe already have
```
performGC
```
which triggers a major garbage collection.
In many cases, it is useful to trigger a minor one; exposing it is as simple as Simon Marlow suggested in https://groups.google.com/d/msg/fa.haskell/-q6sINVa...We already have
```
performGC
```
which triggers a major garbage collection.
In many cases, it is useful to trigger a minor one; exposing it is as simple as Simon Marlow suggested in https://groups.google.com/d/msg/fa.haskell/-q6sINValu8/_Z7odE6O5PsJ.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mail@nh2.me |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Mem: Expose performMinorGC","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mail@nh2.me"],"type":"Bug","description":"We already have\r\n\r\n{{{\r\nperformGC\r\n}}}\r\n\r\nwhich triggers a major garbage collection.\r\n\r\nIn many cases, it is useful to trigger a minor one; exposing it is as simple as Simon Marlow suggested in https://groups.google.com/d/msg/fa.haskell/-q6sINValu8/_Z7odE6O5PsJ.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8256adding locality levels to prefetch# and friends2021-12-23T22:37:26ZCarter Schonwaldadding locality levels to prefetch# and friendscurrently in HEAD / 7.7, the prefetch primop only does the equivalent of __builtin_prefetch(ptr,0,3)
(0 here denoting a read prefetch, 3 denoting "high locality, keep this in cache for a while")
On modern hardware, we can do better! For...currently in HEAD / 7.7, the prefetch primop only does the equivalent of __builtin_prefetch(ptr,0,3)
(0 here denoting a read prefetch, 3 denoting "high locality, keep this in cache for a while")
On modern hardware, we can do better! For many natural use case of prefetch in haskell, we have a streaming workload, so we want a prefetch to also hint that "once we've worked on a piece of memory, no need to keep it around for any period of time, don't pollute our memory with it"
the attached patch takes each prefetchBlah\# operation (where blah=ByteArray,MutableByteArray, or Addr) and replaces it with prefetchBlah0\# through prefetchBlah3\#, and passes the integer information through into the code generators.
To make the engineering reasonable, I enriched MO_Prefetch_Data with an Int parameter (which must be a value between ranging 0-3). Theres probably a better way to model the locality paramter, but that maps directly to how its used in llvm code gen.
This patch does not include a test case yet. (interestingly, currently the test suite doesn't have any tests for the prefetch primops as yet!). So that needs to be added.
Also, theres no good reason for the prefetch ops to be LLVM only.
worst case we could just treat them as noop's and drop them. But at least for x86, should be easy to add the support (though if anyone wants to add support for the ppc and sparc stuff, or help me do that, that'd be awesome too!) . I"ll look into doing that in a few days.
theres probably some other things i'm overlooking.
anyways, i'll attach a preliminary patch for feedback now
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"adding locality levels to prefetch# and friends","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"carter"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"currently in HEAD / 7.7, the prefetch primop only does the equivalent of __builtin_prefetch(ptr,0,3)\r\n(0 here denoting a read prefetch, 3 denoting \"high locality, keep this in cache for a while\")\r\n\r\nOn modern hardware, we can do better! For many natural use case of prefetch in haskell, we have a streaming workload, so we want a prefetch to also hint that \"once we've worked on a piece of memory, no need to keep it around for any period of time, don't pollute our memory with it\"\r\n\r\nthe attached patch takes each prefetchBlah# operation (where blah=ByteArray,MutableByteArray, or Addr) and replaces it with prefetchBlah0# through prefetchBlah3#, and passes the integer information through into the code generators. \r\n\r\nTo make the engineering reasonable, I enriched MO_Prefetch_Data with an Int parameter (which must be a value between ranging 0-3). Theres probably a better way to model the locality paramter, but that maps directly to how its used in llvm code gen.\r\n\r\nThis patch does not include a test case yet. (interestingly, currently the test suite doesn't have any tests for the prefetch primops as yet!). So that needs to be added.\r\n\r\nAlso, theres no good reason for the prefetch ops to be LLVM only. \r\n\r\nworst case we could just treat them as noop's and drop them. But at least for x86, should be easy to add the support (though if anyone wants to add support for the ppc and sparc stuff, or help me do that, that'd be awesome too!) . I\"ll look into doing that in a few days.\r\n\r\ntheres probably some other things i'm overlooking.\r\n\r\nanyways, i'll attach a preliminary patch for feedback now","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8254confusing comment on allocate()2019-07-07T18:45:52Zrwbartonconfusing comment on allocate()```
/* -----------------------------------------------------------------------------
allocate()
This allocates memory in the current thread - it is intended for
use primarily from STG-land where we have a Capability. It is
...```
/* -----------------------------------------------------------------------------
allocate()
This allocates memory in the current thread - it is intended for
use primarily from STG-land where we have a Capability. It is
better than allocate() because it doesn't require taking the
sm_mutex lock in the common case.
Memory is allocated directly from the nursery if possible (but not
from the current nursery block, so as not to interfere with
Hp/HpLim).
-------------------------------------------------------------------------- */
```
Not sure what, if anything, `allocate()` is better than, but it's not `allocate()`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"confusing comment on allocate()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n/* -----------------------------------------------------------------------------\r\n allocate()\r\n\r\n This allocates memory in the current thread - it is intended for\r\n use primarily from STG-land where we have a Capability. It is\r\n better than allocate() because it doesn't require taking the\r\n sm_mutex lock in the common case.\r\n\r\n Memory is allocated directly from the nursery if possible (but not\r\n from the current nursery block, so as not to interfere with\r\n Hp/HpLim).\r\n -------------------------------------------------------------------------- */\r\n}}}\r\n\r\nNot sure what, if anything, `allocate()` is better than, but it's not `allocate()`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8247Dependency tracking (--make) broken for re-exported modules2019-07-07T18:45:53ZGabor GreifDependency tracking (--make) broken for re-exported modulesSay, I re-export a module, from which I hide some bindings:
```
module B (module A) where
import A hiding (a1)
```
where `A` is defined thus:
```
module A where
a1 = 5
a2 = 42
a3 = 113
```
I use `B` from `C`:
```
module C where
impo...Say, I re-export a module, from which I hide some bindings:
```
module B (module A) where
import A hiding (a1)
```
where `A` is defined thus:
```
module A where
a1 = 5
a2 = 42
a3 = 113
```
I use `B` from `C`:
```
module C where
import B
a2 = 142
```
Build `C`, with `ghc --make C.hs`, observing redefinition error (of `a2`).
Now hide also `a2` in `B` like this (by editing `B.hs`):
```
module B (module A) where
import A hiding (a1, a2)
```
Build `C` again, and observe that the error persists, because `B` has not been rebuilt, and its interface file not regenerated.
Deleting `B.hi` and recompiling resolves the situation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"Dependency tracking (--make) broken for re-exported modules","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Say, I re-export a module, from which I hide some bindings:\r\n{{{\r\nmodule B (module A) where\r\nimport A hiding (a1)\r\n}}}\r\nwhere `A` is defined thus:\r\n{{{\r\nmodule A where\r\na1 = 5\r\na2 = 42\r\na3 = 113\r\n}}}\r\n\r\nI use `B` from `C`:\r\n{{{\r\nmodule C where\r\nimport B\r\na2 = 142\r\n}}}\r\n\r\nBuild `C`, with `ghc --make C.hs`, observing redefinition error (of `a2`).\r\n\r\nNow hide also `a2` in `B` like this (by editing `B.hs`):\r\n{{{\r\nmodule B (module A) where\r\nimport A hiding (a1, a2)\r\n}}}\r\n\r\nBuild `C` again, and observe that the error persists, because `B` has not been rebuilt, and its interface file not regenerated.\r\n\r\nDeleting `B.hi` and recompiling resolves the situation.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8245ghc-pkg list --simple-output prints packages in non-alphabetical order2019-07-07T18:45:54ZNiklas Hambüchenmail@nh2.meghc-pkg list --simple-output prints packages in non-alphabetical orderInstead, it prints the ones with the smallest version first.
That does not make much sense.
I will attach a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------...Instead, it prints the ones with the smallest version first.
That does not make much sense.
I will attach a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| 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":"ghc-pkg list prints packages in non-alphabetical order","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Instead, it prints the ones with the smallest version first.\r\n\r\nThat does not make much sense.\r\n\r\nI will attach a patch.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1