GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:40:56Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9309Regression when building the 'sizes' application2019-07-07T18:40:56ZJohnWiegleyRegression when building the 'sizes' applicationI have a package on Hackage called `sizes`. It builds fine with GHC 7.8.2, but when building with 7.8.3 I get:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
make_exp (App _ (Coer...I have a package on Hackage called `sizes`. It builds fine with GHC 7.8.2, but when building with 7.8.3 I get:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
make_exp (App _ (Coercion _))
```7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9294More exports and documentation for GHC API Parser Module2019-07-07T18:41:00ZagibianskyMore exports and documentation for GHC API Parser ModuleI would like to be able to use the GHC API for parsing. Right now this is in the Parser and Lexer modules:
Parser: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Parser.html
Lexer: http://www.haskell.org/ghc/docs/7.8.2/h...I would like to be able to use the GHC API for parsing. Right now this is in the Parser and Lexer modules:
Parser: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Parser.html
Lexer: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Lexer.html
GHC currently exposes only a few parsers here. I'd like to make a few modifications:
1. Expose a few more parsers than currently are exposed in the Parser module. In particular, I'd like import statements, type signatures, declarations, and expressions, at least, in addition to what's already there.
1. Add some Haddock documentation to the top of the Parser module describing how to use it, since the types themselves are pretty opaque here.
1. Export a clean and self-contained parsing API from the GHC module.
See minor discussion here: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/4791
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"More exports and documentation for GHC API Parser Module","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"agibiansky"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"\r\nI would like to be able to use the GHC API for parsing. Right now this is in the Parser and Lexer modules:\r\n\r\nParser: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Parser.html\r\nLexer: http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Lexer.html\r\n\r\nGHC currently exposes only a few parsers here. I'd like to make a few modifications:\r\n\r\n1. Expose a few more parsers than currently are exposed in the Parser module. In particular, I'd like import statements, type signatures, declarations, and expressions, at least, in addition to what's already there.\r\n\r\n2. Add some Haddock documentation to the top of the Parser module describing how to use it, since the types themselves are pretty opaque here.\r\n\r\n3. Export a clean and self-contained parsing API from the GHC module.\r\n\r\nSee minor discussion here: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/4791","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1agibianskyagibianskyhttps://gitlab.haskell.org/ghc/ghc/-/issues/9293GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguage...2019-07-07T18:41:00ZjfeltzGHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension"Any language extension tried appears to not work with :unset. To make matters worse, :unset expands to a number of options, misleading the user into thinking that it should (if that is the case). I eventually had to ask someone on IRC \#...Any language extension tried appears to not work with :unset. To make matters worse, :unset expands to a number of options, misleading the user into thinking that it should (if that is the case). I eventually had to ask someone on IRC \#haskell, leading to the :set -XNoLanguageExtension trick to do what I needed. A fix to :unset is suggested, or removing the misleading/non-working command.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | :set -XCPP followed by :unset -XCPP |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCI :unset -XLanguageExtension returns \"don't know how to reverse -XLanguageExtension\"","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":":set -XCPP followed by :unset -XCPP","architecture":"","cc":["hvr"],"type":"Bug","description":"Any language extension tried appears to not work with :unset. To make matters worse, :unset expands to a number of options, misleading the user into thinking that it should (if that is the case). I eventually had to ask someone on IRC #haskell, leading to the :set -XNoLanguageExtension trick to do what I needed. A fix to :unset is suggested, or removing the misleading/non-working command.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1lerouxlerouxhttps://gitlab.haskell.org/ghc/ghc/-/issues/9284shutdownCapability sometimes loops indefinitely on OSX after forkProcess2019-07-07T18:41:03Zedsko@edsko.netshutdownCapability sometimes loops indefinitely on OSX after forkProcessThe attached Haskell program is a stress test for `forkProcess`. It starts 100 child processes, each of which do a single, safe, FFI call, after which the main process waits for all child processes to terminate.
I compile the test with
...The attached Haskell program is a stress test for `forkProcess`. It starts 100 child processes, each of which do a single, safe, FFI call, after which the main process waits for all child processes to terminate.
I compile the test with
```
# gcc -c -o TestForkProcessC.o -g TestForkProcessC.c
# ghc -debug -threaded -fforce-recomp -Wall TestForkProcess.hs TestForkProcessC.o
```
and then start running it until it fails (that is, until one or more of the child processes fail to terminate):
```
# while ./TestForkProcess +RTS -N1 ; do echo "OK"; done
```
Actually, most of the time this happens pretty quickly (often even on the first call to `TestForkProcess`).
Those child processes that do fail to terminate get stuck in an infinite loop in `shutdownCapability`, which looks something like:
```
void shutdownCapability (Capability *cap, Task *task, rtsBool safe)
{
nat i;
task->cap = cap;
for (i = 0; /* i < 50 */; i++) {
// ... other conditionals omitted
if (cap->suspended_ccalls && safe) {
cap->running_task = NULL;
RELEASE_LOCK(&cap->lock);
// The IO manager thread might have been slow to start up,
// so the first attempt to kill it might not have
// succeeded. Just in case, try again - the kill message
// will only be sent once.
ioManagerDie();
yieldThread();
continue;
}
traceSparkCounters(cap);
RELEASE_LOCK(&cap->lock);
break;
}
}
```
(note that I'm only considering the threaded RTS). In the child processes that loop indefinitely this `cap->suspended_ccalls && safe` condition gets triggered time and again.
When it does, it gets stuck waiting for a single `InCall`. This `InCall` is created by a call to `newInCall` in `workerStart` -- i.e., it is created on pthread startup. That begs the question where this worker task was created; this I don't know for sure but I am fairly sure that it happens during the initialization of the IO manager. (The initialization sequence of the IO manager involves the creation of 4 tasks before we even get to `main`, so it's bit a hard to navigate.)
I have some further evidence that the I/O manager is involved, although not necessarily the cause of the problem. On normal termination, the I/O manager is asked to shutdown by the call to `ioManagerDie` in `shutdownCapability`, shown above. This will send `IO_MANAGER_DIE` (`0xFE`) on the I/O managers "control pipe" (created in `GHC.Event.Thread.startTimerManagerThread`). When the timer manager thread receives this (in `GHC.Event.TimerManager.handleControlEvent`) it calls `shutdownManagers`, which shuts down the IO manager threads by sending them `io_MANAGER_DIE` on their respective pipes. This gets received by `GHC.Event.Manager.handleControlEvent` and the IO manager threads exit. (Note on capitalization: `IO_MANAGER_DIE` is the C symbol; `io_MANAGER_DIE` is the Haskell symbol.)
When the child process fails to terminate, the first part of this process still happens. The timer manager thread receives `IO_MANAGER_DIE` and calls `shutdownManagers`. However, now things go wrong, and it seems they go wrong in one of two ways. The very first thing that `shutdownManagers` does is acquire the `ioManagerLock`. Sometimes it gets stuck right there. However, this is not *always* the case. Sometimes it does manage to acquire the lock, and I can see it going through the loop and sending the shutdown signal to the IO manager thread (I'm saying "the" because I've exclusively been testing with `-N1`). Either way, in the case that the child process gets stuck, this signal somehow never arrives at the IO manager thread (that is, I have a print statement in `readControlMessage` that prints a message when it receives `IO_MANAGER_DIE`, along with a bit of information where it was called from, and that print statement never triggers).
I am not sure where to go from here. Note that I have only been able to reproduce this on OSX/ghc 7.8. I have not been able to reproduce this problem on Linux/7.8 (although there _are_ other problems with `forkProcess` on Linux, which unfortunately are proving even more elusive). The attached stress test *does* very often get stuck on Linux/7.4 but of course that's a different I/O manager altogether and is probably an unrelated bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"shutdownCapability sometimes loops indefinitely on OSX after forkProcess","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached Haskell program is a stress test for `forkProcess`. It starts 100 child processes, each of which do a single, safe, FFI call, after which the main process waits for all child processes to terminate. \r\n\r\nI compile the test with\r\n\r\n{{{\r\n# gcc -c -o TestForkProcessC.o -g TestForkProcessC.c \r\n# ghc -debug -threaded -fforce-recomp -Wall TestForkProcess.hs TestForkProcessC.o \r\n}}}\r\n\r\nand then start running it until it fails (that is, until one or more of the child processes fail to terminate):\r\n\r\n{{{\r\n# while ./TestForkProcess +RTS -N1 ; do echo \"OK\"; done\r\n}}}\r\n\r\nActually, most of the time this happens pretty quickly (often even on the first call to `TestForkProcess`). \r\n\r\nThose child processes that do fail to terminate get stuck in an infinite loop in `shutdownCapability`, which looks something like:\r\n\r\n{{{\r\nvoid shutdownCapability (Capability *cap, Task *task, rtsBool safe)\r\n{\r\n nat i;\r\n task->cap = cap;\r\n\r\n for (i = 0; /* i < 50 */; i++) {\r\n // ... other conditionals omitted\r\n\r\n if (cap->suspended_ccalls && safe) {\r\n cap->running_task = NULL;\r\n\t RELEASE_LOCK(&cap->lock);\r\n // The IO manager thread might have been slow to start up,\r\n // so the first attempt to kill it might not have\r\n // succeeded. Just in case, try again - the kill message\r\n // will only be sent once.\r\n ioManagerDie();\r\n yieldThread();\r\n continue;\r\n }\r\n\r\n traceSparkCounters(cap);\r\n\tRELEASE_LOCK(&cap->lock);\r\n\tbreak;\r\n }\r\n}\r\n}}}\r\n\r\n(note that I'm only considering the threaded RTS). In the child processes that loop indefinitely this `cap->suspended_ccalls && safe` condition gets triggered time and again. \r\n\r\nWhen it does, it gets stuck waiting for a single `InCall`. This `InCall` is created by a call to `newInCall` in `workerStart` -- i.e., it is created on pthread startup. That begs the question where this worker task was created; this I don't know for sure but I am fairly sure that it happens during the initialization of the IO manager. (The initialization sequence of the IO manager involves the creation of 4 tasks before we even get to `main`, so it's bit a hard to navigate.)\r\n\r\nI have some further evidence that the I/O manager is involved, although not necessarily the cause of the problem. On normal termination, the I/O manager is asked to shutdown by the call to `ioManagerDie` in `shutdownCapability`, shown above. This will send `IO_MANAGER_DIE` (`0xFE`) on the I/O managers \"control pipe\" (created in `GHC.Event.Thread.startTimerManagerThread`). When the timer manager thread receives this (in `GHC.Event.TimerManager.handleControlEvent`) it calls `shutdownManagers`, which shuts down the IO manager threads by sending them `io_MANAGER_DIE` on their respective pipes. This gets received by `GHC.Event.Manager.handleControlEvent` and the IO manager threads exit. (Note on capitalization: `IO_MANAGER_DIE` is the C symbol; `io_MANAGER_DIE` is the Haskell symbol.)\r\n\r\nWhen the child process fails to terminate, the first part of this process still happens. The timer manager thread receives `IO_MANAGER_DIE` and calls `shutdownManagers`. However, now things go wrong, and it seems they go wrong in one of two ways. The very first thing that `shutdownManagers` does is acquire the `ioManagerLock`. Sometimes it gets stuck right there. However, this is not ''always'' the case. Sometimes it does manage to acquire the lock, and I can see it going through the loop and sending the shutdown signal to the IO manager thread (I'm saying \"the\" because I've exclusively been testing with `-N1`). Either way, in the case that the child process gets stuck, this signal somehow never arrives at the IO manager thread (that is, I have a print statement in `readControlMessage` that prints a message when it receives `IO_MANAGER_DIE`, along with a bit of information where it was called from, and that print statement never triggers).\r\n\r\nI am not sure where to go from here. Note that I have only been able to reproduce this on OSX/ghc 7.8. I have not been able to reproduce this problem on Linux/7.8 (although there _are_ other problems with `forkProcess` on Linux, which unfortunately are proving even more elusive). The attached stress test ''does'' very often get stuck on Linux/7.4 but of course that's a different I/O manager altogether and is probably an unrelated bug. ","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9281Rewrite `integer-gmp` to use only non-allocating GMP functions2019-07-07T18:41:04ZHerbert Valerio Riedelhvr@gnu.orgRewrite `integer-gmp` to use only non-allocating GMP functionsAfter some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions.
If successful, this would
- allo...After some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions.
If successful, this would
- allow to avoid the custom GMP allocator hack, and thus
- avoid issues when linking against other C libraries using GMP,
- simplify code, as we would perform all heap allocations in Haskell code (and never inside Cmm/C code as its done now),
- and finally maybe even remove a few more superfluous temporary heap allocations.
see also wiki:Design/IntegerGmp27.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9268internal error: evacuate(static): strange closure type -3858759682019-07-07T18:41:07Zbrbrinternal error: evacuate(static): strange closure type -385875968From a fresh checkout
```
$ git describe
ghc-7.9-start-4689-g0567a31
```
and "make -j3" of the "quick-llvm" profile:
```
inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes B...From a fresh checkout
```
$ git describe
ghc-7.9-start-4689-g0567a31
```
and "make -j3" of the "quick-llvm" profile:
```
inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet"
dll-split: internal error: evacuate(static): strange closure type -385875968
(GHC version 7.9.20140704 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped)
make[1]: *** Waiting for unfinished jobs....
<<ghc: 1842198088 bytes, 249 GCs, 9848554/24268488 avg/max bytes residency (7 samples), 62M in use, 0.00 INIT (0.00 elapsed), 1.54 MUT (3.48 elapsed), 0.35 GC (0.37 elapsed) :ghc>>
make: *** [all] Error 2
```
Host GHC:
```
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","/usr/bin/gcc")
,("C compiler flags"," -fno-stack-protector")
,("C compiler link flags","")
,("ld command","/usr/bin/ld")
,("ld flags","")
,("ld supports compact unwind","YES")
,("ld supports build-id","YES")
,("ld supports filelist","NO")
,("ld is GNU ld","YES")
,("ar command","/usr/bin/ar")
,("ar flags","q")
,("ar supports at file","YES")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("libtool command","libtool")
,("perl command","/usr/bin/perl")
,("target os","OSLinux")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","True")
,("target has .ident directive","True")
,("target has subsections via symbols","False")
,("Unregisterised","NO")
,("LLVM llc command","llc")
,("LLVM opt command","opt")
,("Project version","7.8.2")
,("Booter version","7.4.1")
,("Stage","2")
,("Build platform","x86_64-unknown-linux")
,("Host platform","x86_64-unknown-linux")
,("Target platform","x86_64-unknown-linux")
,("Have interpreter","YES")
,("Object splitting supported","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
,("Support dynamic-too","YES")
,("Support parallel --make","YES")
,("Dynamic by default","NO")
,("GHC Dynamic","YES")
,("Leading underscore","NO")
,("Debug on","False")
,("LibDir","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2")
,("Global Package DB","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2/package.conf.d")
]
```7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9265Create PackageKey to replace PackageId, including version dependency information2019-07-07T18:41:08ZEdward Z. YangCreate PackageKey to replace PackageId, including version dependency information[Multipleinstalledinstancesofapackage](commentary/packages/multi-instances) has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoC project](wiki:Commentary/GSoCMultipleInstances) that ultimately nev...[Multipleinstalledinstancesofapackage](commentary/packages/multi-instances) has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoC project](wiki:Commentary/GSoCMultipleInstances) that ultimately never got merged into HEAD.
This ticket is our latest attack on the problem, summarized as: add a version dependency hash to the `PackageId` (NOT the `InstalledPackageId`) associated with packages in the database. This approach is distinguished from the prior attempts as follows:
- We make no attempt to support multiple installations of different ways or ABI-compatible versions of a library (e.g. with/without optimizations.) This corresponds to supporting multiple InstalledPackageIds in a database; in our case, we're supporting multiple `PackageId`.
- We do not have to deal with conflicting "instances" in GHC's package resolver: multiple instances can be simultaneously loaded and used in a single compiled program. This is because PackageIds are baked into the exported linker symbols, so different versions will have different names and can peacefully coexist.
- We do not have to deal with the delicate ordering problem of calculating an ABI hash when configuring a package, which is prior to when we actually know it (ABI hash is only known after compilation), because our hash is based ONLY on dependency resolution choice.
- In absence of preference for previously installed packages, our Cabal dependency resolution stays exactly the same: Cabal picks versions, and from these choices we calculate the dependency hashes. With preference, we will have to do a little more work.
- We do not attempt to garbage collect old packages. Because we are not dependent on ABI, there is not an explosion of installed pacakges from package development; new installed packages only occur when version numbers are bumped up, or packages are installed in a combinatorially different fashion.7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9243Recompilation avoidance doesn't work for -fno-code/-fwrite-interface2019-07-07T18:41:13ZEdward Z. YangRecompilation avoidance doesn't work for -fno-code/-fwrite-interfaceWith the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface fil...With the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface files are up-to-date.
However, this does not currently work: we always re-typecheck:
```
t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface
[1 of 1] Compiling A ( A.hs, nothing )
t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface
[1 of 1] Compiling A ( A.hs, nothing )
```
The reason for this is that recompilation avoidance logic in `compileOne` (in `DriverPipeline.hs`) seems to rely exclusively on "linkables" in order to figure out if source has been modified or not. We never generate an object file with `-fwrite-interface`, so the compiler always concludes that we need to retypecheck.
However, recompilation avoidance for hs-boot does work. The reason for this is because we create a dummy o-boot linkable. We can't use this strategy for `-fno-code`, because the dummy object file would imply that we actually compiled the file (which we didn't).
The upshot is that to fix this problem, it looks like we might have to rejigger all of the logic in `compileOne`, which why I gave up on this for now.
Related to https://github.com/haskell/cabal/issues/1179
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| 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":"Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface files are up-to-date.\r\n\r\nHowever, this does not currently work: we always re-typecheck:\r\n\r\n{{{\r\nt-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface\r\n[1 of 1] Compiling A ( A.hs, nothing )\r\nt-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface\r\n[1 of 1] Compiling A ( A.hs, nothing )\r\n}}}\r\n\r\nThe reason for this is that recompilation avoidance logic in `compileOne` (in `DriverPipeline.hs`) seems to rely exclusively on \"linkables\" in order to figure out if source has been modified or not. We never generate an object file with `-fwrite-interface`, so the compiler always concludes that we need to retypecheck.\r\n\r\nHowever, recompilation avoidance for hs-boot does work. The reason for this is because we create a dummy o-boot linkable. We can't use this strategy for `-fno-code`, because the dummy object file would imply that we actually compiled the file (which we didn't).\r\n\r\nThe upshot is that to fix this problem, it looks like we might have to rejigger all of the logic in `compileOne`, which why I gave up on this for now.\r\n\r\nRelated to https://github.com/haskell/cabal/issues/1179","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9240"read . show ≡ id" not satisfied by Data.Fixed2019-07-07T18:41:13ZHerbert Valerio Riedelhvr@gnu.org"read . show ≡ id" not satisfied by Data.FixedAs pointed out in #9231, the desired property "read . show ≡ id" is not satisfied for all resolutions. For instance, consider the following example:
```hs
> data B7
> instance HasResolution B7 where resolution _ = 128
> 1.070 :: Fixed ...As pointed out in #9231, the desired property "read . show ≡ id" is not satisfied for all resolutions. For instance, consider the following example:
```hs
> data B7
> instance HasResolution B7 where resolution _ = 128
> 1.070 :: Fixed B7
1.062
> 1.062 :: Fixed B7
1.054
> read "1.070" :: Fixed B7
1.062
> read "1.062" :: Fixed B7
1.054
```
This behaviour can be reproduced all the way back to GHC 7.2.17.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9230Make -fwarn-tabs the default2019-07-07T18:41:16ZDavid FeuerMake -fwarn-tabs the defaultTabs trip up an awful lot of Haskell beginners. Turning the warning on by default will likely save them a lot of grief. Any insane\^h\^h\^h\^h\^h\^hexperienced Haskellers who like tabs will have no trouble disabling the warning in their ...Tabs trip up an awful lot of Haskell beginners. Turning the warning on by default will likely save them a lot of grief. Any insane\^h\^h\^h\^h\^h\^hexperienced Haskellers who like tabs will have no trouble disabling the warning in their pragmas.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| 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":"Make -fwarn-tabs the default","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Tabs trip up an awful lot of Haskell beginners. Turning the warning on by default will likely save them a lot of grief. Any insane^h^h^h^h^h^hexperienced Haskellers who like tabs will have no trouble disabling the warning in their pragmas.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1mlenmlenhttps://gitlab.haskell.org/ghc/ghc/-/issues/9224Add support for binary integer literals2019-07-07T18:41:18ZHerbert Valerio Riedelhvr@gnu.orgAdd support for binary integer literalsHaskell2010 supports
- base-10 (prefix-less),
- base-8 (via `0[oO]`-prefix), and
- base-16 (via `0[xX]`-prefix) integer literals.
I hereby propose to add conditional support for base-2 integers literals via a `0[bB]`-prefix, disabled b...Haskell2010 supports
- base-10 (prefix-less),
- base-8 (via `0[oO]`-prefix), and
- base-16 (via `0[xX]`-prefix) integer literals.
I hereby propose to add conditional support for base-2 integers literals via a `0[bB]`-prefix, disabled by default, and controllable via a new `{-# LANGUAGE BinaryLiterals #-}` language extension flag/pragma.
The use of a `0b` prefix for indicating binary literals is known
from popular programming languages such as Python, Ruby, and Java.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9220type roles for unboxed arrays2019-07-07T18:41:19Zrwbartontype roles for unboxed arrays```
rwbarton@morphism:~$ ghci
GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelu...```
rwbarton@morphism:~$ ghci
GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :i Data.Array.Unboxed.UArray
type role Data.Array.Base.UArray representational phantom
data Data.Array.Base.UArray i e
= Data.Array.Base.UArray !i
!i
{-# UNPACK #-} !Int
GHC.Prim.ByteArray#
-- Defined in ‘Data.Array.Base’
-- [instances trimmed]
Prelude> :i Data.Array.IO.IOUArray
type role Data.Array.IO.Internals.IOUArray representational phantom
newtype Data.Array.IO.Internals.IOUArray i e
= Data.Array.IO.Internals.IOUArray (Data.Array.Base.STUArray
GHC.Prim.RealWorld i e)
-- Defined in ‘Data.Array.IO.Internals’
Prelude> :i Data.Array.ST.STUArray
type role Data.Array.Base.STUArray nominal representational phantom
data Data.Array.Base.STUArray s i e
= Data.Array.Base.STUArray !i
!i
{-# UNPACK #-} !Int
(GHC.Prim.MutableByteArray# s)
-- Defined in ‘Data.Array.Base’
Prelude> :i Data.Array.Storable.StorableArray
type role Data.Array.Storable.Internals.StorableArray representational phantom
data Data.Array.Storable.Internals.StorableArray i e
= Data.Array.Storable.Internals.StorableArray !i
!i
Int
!(GHC.ForeignPtr.ForeignPtr e)
-- Defined in ‘Data.Array.Storable.Internals’
```
These phantom roles for the element types let me create an unboxed array of one type (like Word8), cast it with `coerce` to another type (like Word64) and read outside the bounds of the array. I think they should all be nominal, since a newtype of an existing type could have a totally unrelated MArray or Storable instance.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.8.1 |
| 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":"type roles for unboxed arrays","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nrwbarton@morphism:~$ ghci\r\nGHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nPrelude> :i Data.Array.Unboxed.UArray\r\ntype role Data.Array.Base.UArray representational phantom\r\ndata Data.Array.Base.UArray i e\r\n = Data.Array.Base.UArray !i\r\n !i\r\n {-# UNPACK #-} !Int\r\n GHC.Prim.ByteArray#\r\n \t-- Defined in ‘Data.Array.Base’\r\n-- [instances trimmed]\r\nPrelude> :i Data.Array.IO.IOUArray\r\ntype role Data.Array.IO.Internals.IOUArray representational phantom\r\nnewtype Data.Array.IO.Internals.IOUArray i e\r\n = Data.Array.IO.Internals.IOUArray (Data.Array.Base.STUArray\r\n GHC.Prim.RealWorld i e)\r\n \t-- Defined in ‘Data.Array.IO.Internals’\r\nPrelude> :i Data.Array.ST.STUArray\r\ntype role Data.Array.Base.STUArray nominal representational phantom\r\ndata Data.Array.Base.STUArray s i e\r\n = Data.Array.Base.STUArray !i\r\n !i\r\n {-# UNPACK #-} !Int\r\n (GHC.Prim.MutableByteArray# s)\r\n \t-- Defined in ‘Data.Array.Base’\r\nPrelude> :i Data.Array.Storable.StorableArray\r\ntype role Data.Array.Storable.Internals.StorableArray representational phantom\r\ndata Data.Array.Storable.Internals.StorableArray i e\r\n = Data.Array.Storable.Internals.StorableArray !i\r\n !i\r\n Int\r\n !(GHC.ForeignPtr.ForeignPtr e)\r\n \t-- Defined in ‘Data.Array.Storable.Internals’\r\n}}}\r\n\r\nThese phantom roles for the element types let me create an unboxed array of one type (like Word8), cast it with `coerce` to another type (like Word64) and read outside the bounds of the array. I think they should all be nominal, since a newtype of an existing type could have a totally unrelated MArray or Storable instance.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/9201GHC unexpectedly refines explicit kind signatures2019-07-07T18:41:24ZEdward KmettGHC unexpectedly refines explicit kind signaturesThe following program should be rejected by the type checker:
```
{-# LANGUAGE PolyKinds, FunctionalDependencies, MultiParamTypeClasses #-}
class MonoidalCCC (f :: x -> y) (d :: y -> y -> *) | f -> d where
ret :: d a (f a)
```
Inste...The following program should be rejected by the type checker:
```
{-# LANGUAGE PolyKinds, FunctionalDependencies, MultiParamTypeClasses #-}
class MonoidalCCC (f :: x -> y) (d :: y -> y -> *) | f -> d where
ret :: d a (f a)
```
Instead it is accepted, but the kind variables specified above are 'corrected' during typechecking to:
```
>>> :browse
class MonoidalCCC (f :: x -> x) (d :: x -> x -> *) | f -> d where
ret :: d a (f a)
```
This may be similar in root cause to issue #9200, but there a valid program is rejected, and here an invalid program is accepted, so the fixes may be quite different.
It seems these kind variables are just being allowed to unify rather than being checked for subsumption.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC unexpectedly refines explicit kind signatures","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"The following program should be rejected by the type checker:\r\n\r\n{{{\r\n{-# LANGUAGE PolyKinds, FunctionalDependencies, MultiParamTypeClasses #-}\r\n\r\nclass MonoidalCCC (f :: x -> y) (d :: y -> y -> *) | f -> d where\r\n ret :: d a (f a)\r\n}}}\r\n\r\nInstead it is accepted, but the kind variables specified above are 'corrected' during typechecking to:\r\n\r\n{{{\r\n>>> :browse\r\nclass MonoidalCCC (f :: x -> x) (d :: x -> x -> *) | f -> d where\r\n ret :: d a (f a)\r\n}}}\r\n\r\nThis may be similar in root cause to issue #9200, but there a valid program is rejected, and here an invalid program is accepted, so the fixes may be quite different.\r\n\r\nIt seems these kind variables are just being allowed to unify rather than being checked for subsumption.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9200Milner-Mycroft failure at the kind level2019-07-07T18:41:24ZEdward KmettMilner-Mycroft failure at the kind levelThis is a reduction of a problem that occurs in real code.
```
{-# LANGUAGE PolyKinds #-}
class D a => C (f :: k) a
class C () a => D a
```
Typechecking complains:
```
The first argument of ‘C’ should have kind ‘k’,
but ‘()’...This is a reduction of a problem that occurs in real code.
```
{-# LANGUAGE PolyKinds #-}
class D a => C (f :: k) a
class C () a => D a
```
Typechecking complains:
```
The first argument of ‘C’ should have kind ‘k’,
but ‘()’ has kind ‘*’
In the class declaration for ‘D’
```
This program should be accepted, but we're not generalizing enough.
A slightly less reduced version of the problem arises in practice in:
```
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE PolyKinds #-}
import Control.Category
class (Category c, Category d, Category e) => Profunctor
(p :: x -> y -> z)
(c :: x -> x -> *)
(d :: y -> y -> *)
(e :: z -> z -> *)
| p -> c d e
-- lens-style isomorphism families in an arbitrary category
type Iso (c :: i -> i -> *) (s :: i) (a :: i) = forall (p :: i -> i -> *).
Profunctor p c c (->) => p a a -> p s s
class Category e => Cartesian (e :: z -> z -> *) where
type P e :: z -> z -> z
associate :: Iso e (P e (P e a b) c) (P e a (P e b c))
```
This typechecks, but if I replace the line
```
class (Category c, Category d, Category e) => Profunctor
```
with
```
class (Category c, Category d, Cartesian e) => Profunctor
```
to say that you can only enrich a category over a monoidal category (using `Cartesian` in the approximation here), then it fails because a more baroque version of the same kind of cycle as the minimal example above as Profunctor references Cartesian which references an Iso which mentions a Profunctor.
I'm supplying explicit kind variables in the signature of the class, so we should be able to use those like we do with function signatures a universe down. =/
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Milner-Mycroft failure at the kind level","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"This is a reduction of a problem that occurs in real code.\r\n\r\n{{{\r\n{-# LANGUAGE PolyKinds #-}\r\nclass D a => C (f :: k) a\r\nclass C () a => D a\r\n}}}\r\n\r\nTypechecking complains:\r\n\r\n{{{\r\n The first argument of ‘C’ should have kind ‘k’,\r\n but ‘()’ has kind ‘*’\r\n In the class declaration for ‘D’\r\n}}}\r\n\r\nThis program should be accepted, but we're not generalizing enough.\r\n\r\nA slightly less reduced version of the problem arises in practice in:\r\n\r\n{{{\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE FunctionalDependencies #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n\r\nimport Control.Category\r\n\r\nclass (Category c, Category d, Category e) => Profunctor\r\n (p :: x -> y -> z)\r\n (c :: x -> x -> *)\r\n (d :: y -> y -> *)\r\n (e :: z -> z -> *)\r\n | p -> c d e\r\n\r\n-- lens-style isomorphism families in an arbitrary category\r\ntype Iso (c :: i -> i -> *) (s :: i) (a :: i) = forall (p :: i -> i -> *). \r\n Profunctor p c c (->) => p a a -> p s s\r\n\r\nclass Category e => Cartesian (e :: z -> z -> *) where\r\n type P e :: z -> z -> z\r\n associate :: Iso e (P e (P e a b) c) (P e a (P e b c))\r\n}}}\r\n\r\nThis typechecks, but if I replace the line\r\n\r\n{{{\r\nclass (Category c, Category d, Category e) => Profunctor\r\n}}}\r\n\r\nwith \r\n\r\n{{{\r\nclass (Category c, Category d, Cartesian e) => Profunctor\r\n}}}\r\n\r\nto say that you can only enrich a category over a monoidal category (using `Cartesian` in the approximation here), then it fails because a more baroque version of the same kind of cycle as the minimal example above as Profunctor references Cartesian which references an Iso which mentions a Profunctor.\r\n\r\nI'm supplying explicit kind variables in the signature of the class, so we should be able to use those like we do with function signatures a universe down. =/","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/9196Higher-rank constraint treated as type instead2019-07-07T18:41:26ZRichard Eisenbergrae@richarde.devHigher-rank constraint treated as type insteadWhen I say
```
{-# LANGUAGE RankNTypes #-}
module Bug where
class P z
foo :: (forall b. P (a, b)) => a -> a
foo x = x
```
I get
```
Bug.hs:7:9:
Couldn't match expected type ‘a -> a’ with actual type ‘P (a, b0)’
Relevant bind...When I say
```
{-# LANGUAGE RankNTypes #-}
module Bug where
class P z
foo :: (forall b. P (a, b)) => a -> a
foo x = x
```
I get
```
Bug.hs:7:9:
Couldn't match expected type ‘a -> a’ with actual type ‘P (a, b0)’
Relevant bindings include
x :: forall b. P (a, b) (bound at Bug.hs:7:5)
foo :: (forall b. P (a, b)) -> a -> a (bound at Bug.hs:7:1)
In the expression: x
In an equation for ‘foo’: foo x = x
```
I expected my code to be rejected, but not with that error message. It seems that GHC thinks `forall b. P (a, b))` has kind `*`, not kind `Constraint`.
Encountered while experimenting with #9195.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Higher-rank constraint treated as type instead","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{\r\n{-# LANGUAGE RankNTypes #-}\r\n\r\nmodule Bug where\r\n\r\nclass P z\r\nfoo :: (forall b. P (a, b)) => a -> a\r\nfoo x = x\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\nBug.hs:7:9:\r\n Couldn't match expected type ‘a -> a’ with actual type ‘P (a, b0)’\r\n Relevant bindings include\r\n x :: forall b. P (a, b) (bound at Bug.hs:7:5)\r\n foo :: (forall b. P (a, b)) -> a -> a (bound at Bug.hs:7:1)\r\n In the expression: x\r\n In an equation for ‘foo’: foo x = x\r\n}}}\r\n\r\nI expected my code to be rejected, but not with that error message. It seems that GHC thinks `forall b. P (a, b))` has kind `*`, not kind `Constraint`.\r\n\r\nEncountered while experimenting with #9195.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9189Linking fails on OSX when -staticlib and -threaded are enabled2019-07-07T18:41:28ZfrodeLinking fails on OSX when -staticlib and -threaded are enabledI'm trying to build a library with ffi exported functions to be called from ObjectiveC in an Xcode project on OSX. With just -staticlib it works, but when I add -threaded as well I get a linker error saying that it cannot find pthread. T...I'm trying to build a library with ffi exported functions to be called from ObjectiveC in an Xcode project on OSX. With just -staticlib it works, but when I add -threaded as well I get a linker error saying that it cannot find pthread. This happens even with a trivial program:
```
Test.hs:
module Test where
main :: IO ()
main = putStrLn "Hello"
```
```
$ ghc Test.hs -staticlib -threaded
[1 of 1] Compiling Test ( Test.hs, Test.o )
Linking liba.a ...
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)
```
The linker command that fails:
```
*** Linker:
libtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread
```
If I make a script that removes the -lpthread argument, it links ok and the project works with multiple threads calling my ffi-functions simultaneously.
It was suggested by Bob on Haskell Cafe that it should not link against libpthread on OSX since it is included in libSystem (like IOS): https://groups.google.com/d/msg/haskell-cafe/GGEkifs_-uY/uzHeV-Z2E2YJ
https://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs\#L1869-L1873
OSX version 10.9.3
Verbose output:
```
$ ghc Test.hs -staticlib -threaded -v
Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3
Using binary package database: /usr/local/lib/ghc-7.8.2/package.conf.d/package.cache
Using binary package database: /Users/frode/.ghc/x86_64-darwin-7.8.2/package.conf.d/package.cache
hiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0
hiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7
hiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7
wired-in package ghc-prim mapped to ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8
wired-in package integer-gmp mapped to integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99
wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
hiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0
hiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7
hiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7
wired-in package ghc-prim mapped to ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8
wired-in package integer-gmp mapped to integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99
wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *Test.hs
Stable obj: [Test]
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2014-06-10 10:02:41 UTC
ms_mod = main:Test,
ms_textual_imps = [import (implicit) Prelude]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file Test.hs
Created temporary directory: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0
*** Checking old interface for main:Test:
[1 of 1] Skipping Test ( Test.hs, Test.o )
Upsweep completely successful.
*** Deleting temp files:
Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s
Warning: deleting non-existent /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s
link: linkables are ...
LinkableM (2014-06-10 10:02:55 UTC) main:Test
[DotO Test.o]
Linking liba.a ...
*** C Compiler:
/usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c -o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -I/usr/local/lib/ghc-7.8.2/include
*** Linker:
libtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)
*** Deleting temp files:
Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c
*** Deleting temp dirs:
Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Linking fails on OSX when -staticlib and -threaded are enabled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":["pthread","staticlib","threaded"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to build a library with ffi exported functions to be called from ObjectiveC in an Xcode project on OSX. With just -staticlib it works, but when I add -threaded as well I get a linker error saying that it cannot find pthread. This happens even with a trivial program:\r\n\r\n\r\n{{{\r\nTest.hs:\r\nmodule Test where\r\nmain :: IO ()\r\nmain = putStrLn \"Hello\"\r\n}}}\r\n\r\n\r\n{{{\r\n$ ghc Test.hs -staticlib -threaded\r\n[1 of 1] Compiling Test ( Test.hs, Test.o )\r\nLinking liba.a ...\r\nerror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread\r\nerror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)\r\n}}}\r\n\r\nThe linker command that fails:\r\n\r\n{{{\r\n*** Linker:\r\nlibtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread\r\n}}}\r\n\r\nIf I make a script that removes the -lpthread argument, it links ok and the project works with multiple threads calling my ffi-functions simultaneously.\r\n\r\nIt was suggested by Bob on Haskell Cafe that it should not link against libpthread on OSX since it is included in libSystem (like IOS): https://groups.google.com/d/msg/haskell-cafe/GGEkifs_-uY/uzHeV-Z2E2YJ \r\n\r\nhttps://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs#L1869-L1873\r\n\r\n\r\nOSX version 10.9.3\r\nVerbose output:\r\n\r\n{{{\r\n$ ghc Test.hs -staticlib -threaded -v\r\nGlasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3\r\nUsing binary package database: /usr/local/lib/ghc-7.8.2/package.conf.d/package.cache\r\nUsing binary package database: /Users/frode/.ghc/x86_64-darwin-7.8.2/package.conf.d/package.cache\r\nhiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0\r\nhiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7\r\nhiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7\r\nwired-in package ghc-prim mapped to ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8\r\nwired-in package integer-gmp mapped to integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99\r\nwired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\nHsc static flags:\r\nhiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0\r\nhiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7\r\nhiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7\r\nwired-in package ghc-prim mapped to ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8\r\nwired-in package integer-gmp mapped to integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99\r\nwired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\n*** Chasing dependencies:\r\nChasing modules from: *Test.hs\r\nStable obj: [Test]\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = 2014-06-10 10:02:41 UTC\r\n ms_mod = main:Test,\r\n ms_textual_imps = [import (implicit) Prelude]\r\n ms_srcimps = []\r\n }]\r\n*** Deleting temp files:\r\nDeleting:\r\ncompile: input file Test.hs\r\nCreated temporary directory: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0\r\n*** Checking old interface for main:Test:\r\n[1 of 1] Skipping Test ( Test.hs, Test.o )\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s\r\nWarning: deleting non-existent /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s\r\nlink: linkables are ...\r\nLinkableM (2014-06-10 10:02:55 UTC) main:Test\r\n [DotO Test.o]\r\nLinking liba.a ...\r\n*** C Compiler:\r\n/usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c -o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -I/usr/local/lib/ghc-7.8.2/include\r\n*** Linker:\r\nlibtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread\r\nerror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread\r\nerror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)\r\n*** Deleting temp files:\r\nDeleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c\r\n*** Deleting temp dirs:\r\nDeleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9186GHC panic when compiling compdata2019-07-07T18:41:29ZMichael Snoymanmichael@snoyman.comGHC panic when compiling compdataWhen testing ghc-7.8.2.20140609 with Stackage, I came across the following ghc panic:
```
[51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, dist/build/Data/Comp/Ordering.o )
ghc: panic! (the 'impossible' happened)
(...When testing ghc-7.8.2.20140609 with Stackage, I came across the following ghc panic:
```
[51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, dist/build/Data/Comp/Ordering.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.2.20140609 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc4836_0/ghc4836_257.so: undefined symbol: compdatazm0zi8zi1zi0_DataziCompziDeriveziUtils_zdwabstractConType_info
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Failed to install compdata-0.8.1.0
```7.10.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9185glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknown archs2019-07-07T18:41:29ZJens Petersenglibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknown archsStg.h defines _BSD_SOURCE which glibc 2.20 deprecates with warnings
in favour of _DEFAULT_SOURCE. Since the verbose warning is output
for every ghc invocation when building it is rather annoying and
induces testsuite failures.
The warni...Stg.h defines _BSD_SOURCE which glibc 2.20 deprecates with warnings
in favour of _DEFAULT_SOURCE. Since the verbose warning is output
for every ghc invocation when building it is rather annoying and
induces testsuite failures.
The warning look like this:
```
In file included from /usr/include/math.h:26:0:
0,
from /usr/lib64/ghc-7.6.3/include/Stg.h:65,
from /tmp/ghc783_0/ghc783_0.hc:3:
/usr/include/features.h:148:3:
warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
^
```
Solution/workaround is to define "_DEFAULT_SOURCE" and that works.
I asked in https://bugzilla.redhat.com/show_bug.cgi?id=1067110\#c13 about how best to fix Stg.h and got the answer to just add _DEFAULT_SOURCE.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"glibc 2.20 outputs warnings for _BSD_SOURCE (Stg.h) on unknowns archs","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Stg.h defines _BSD_SOURCE which glibc 2.20 deprecates with warnings\r\nin favour of _DEFAULT_SOURCE. Since the verbose warning is output\r\nfor every ghc invocation when building it is rather annoying and\r\ninduces testsuite failures.\r\n\r\nThe warning look like this:\r\n{{{\r\nIn file included from /usr/include/math.h:26:0:\r\n 0,\r\n from /usr/lib64/ghc-7.6.3/include/Stg.h:65,\r\n from /tmp/ghc783_0/ghc783_0.hc:3:\r\n/usr/include/features.h:148:3:\r\n warning: #warning \"_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE\" [-Wcpp]\r\n # warning \"_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE\"\r\n ^\r\n}}}\r\n\r\nSolution/workaround is to define \"_DEFAULT_SOURCE\" and that works.\r\n\r\nI asked in https://bugzilla.redhat.com/show_bug.cgi?id=1067110#c13 about how best to fix Stg.h and got the answer to just add _DEFAULT_SOURCE.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Jens PetersenJens Petersenhttps://gitlab.haskell.org/ghc/ghc/-/issues/9177Suggest Int when user uses int2019-07-07T18:41:31ZJoachim Breitnermail@joachim-breitner.deSuggest Int when user uses intThis ticket is a fork of #1388. We already give suggestions when the user mispells names, based on edit distance. But this does not cross the boundaries between different kind of names.
It would be helpful if `Not in scope: type variabl...This ticket is a fork of #1388. We already give suggestions when the user mispells names, based on edit distance. But this does not cross the boundaries between different kind of names.
It would be helpful if `Not in scope: type variable `int'` would also say `Did you mean the type constructor `Int'`?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| 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":"Suggest Int when user uses int","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This ticket is a fork of #1388. We already give suggestions when the user mispells names, based on edit distance. But this does not cross the boundaries between different kind of names.\r\n\r\nIt would be helpful if {{{Not in scope: type variable `int'}}} would also say {{{Did you mean the type constructor `Int'}}}?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Joachim Breitnermail@joachim-breitner.deJoachim Breitnermail@joachim-breitner.dehttps://gitlab.haskell.org/ghc/ghc/-/issues/9169Add mkWeakTMVar to Control.Concurrent.STM.TMVar2019-07-07T18:41:33ZbasvandijkAdd mkWeakTMVar to Control.Concurrent.STM.TMVarI just needed a Weak pointer to a TMVar:
```
-- | Make a 'Weak' pointer to a 'TMVar', using the second argument as
-- a finalizer to run when 'TMVar' is garbage-collected.
mkWeakTMVar :: TMVar a -> IO () -> IO (Weak (TMVar a))
mkWeakTMV...I just needed a Weak pointer to a TMVar:
```
-- | Make a 'Weak' pointer to a 'TMVar', using the second argument as
-- a finalizer to run when 'TMVar' is garbage-collected.
mkWeakTMVar :: TMVar a -> IO () -> IO (Weak (TMVar a))
mkWeakTMVar tmv@(TMVar (TVar t#)) f = IO $ \s ->
case mkWeak# t# tmv f s of (# s1, w #) -> (# s1, Weak w #)
```
It might make sense to add a similar function for TSem as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add mkWeakTMVar to Control.Concurrent.STM.TMVar","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":["stm"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I just needed a Weak pointer to a TMVar:\r\n\r\n{{{\r\n-- | Make a 'Weak' pointer to a 'TMVar', using the second argument as\r\n-- a finalizer to run when 'TMVar' is garbage-collected.\r\nmkWeakTMVar :: TMVar a -> IO () -> IO (Weak (TMVar a))\r\nmkWeakTMVar tmv@(TMVar (TVar t#)) f = IO $ \\s ->\r\n case mkWeak# t# tmv f s of (# s1, w #) -> (# s1, Weak w #)\r\n}}}\r\n\r\nIt might make sense to add a similar function for TSem as well.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1thoughtpolicethoughtpolice