GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-02-21T17:01:00Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/18247-ddump-minimal-imports does not dump some pattern imports correctly2023-02-21T17:01:00Zjrp2014-ddump-minimal-imports does not dump some pattern imports correctly## Summary
The minimal imports generated by `-ddump-minimal-imports` are sometimes not correct.
For example, it generates `import Agda.Utils.List1 ( pattern (:|) )` correctly, but doesn't include the `pattern` keyword for `Def` in `imp...## Summary
The minimal imports generated by `-ddump-minimal-imports` are sometimes not correct.
For example, it generates `import Agda.Utils.List1 ( pattern (:|) )` correctly, but doesn't include the `pattern` keyword for `Def` in `import qualified Agda.Syntax.Abstract as A ( QName, NameToExpr(nameToExpr), Expr(Con), Def )`, where `Def` is defined in the `Agda.Syntax.Abstract` module as:
```haskell
-- | Pattern synonym for regular Def
pattern Def :: QName -> Expr
pattern Def x = Def' x NoSuffix
```
This limits the utility of the feature.
## Environment
* GHC version used: 8.10.1
* OS; MacOS Catalina8.10.2Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/18217Unable build 8.10.1 on s390x2020-07-23T15:33:05Zmimi.vxUnable build 8.10.1 on s390x## Summary
On s390x build stops with:
```
[ 4466s] "inplace/bin/ghc-stage1" -optc-Wall -optc-Wno-return-type -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpo...## Summary
On s390x build stops with:
```
[ 4466s] "inplace/bin/ghc-stage1" -optc-Wall -optc-Wno-return-type -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_thr\" -optc-ffunction-sections -optc-fdata-sections -static -optc-DTHREADED_RTS -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.thr_o
[ 4466s] In file included from includes/Stg.h:318,
[ 4466s]
[ 4466s] from rts/StgCRun.c:45:0: error:
[ 4466s]
[ 4466s] includes/stg/Regs.h:442:2: error:
[ 4466s] error: #error BaseReg must be in a register for THREADED_RTS
[ 4466s] 442 | #error BaseReg must be in a register for THREADED_RTS
[ 4466s] | ^~~~~
[ 4466s] |
[ 4466s] 442 | #error BaseReg must be in a register for THREADED_RTS
[ 4466s] | ^
[ 4466s] In file included from includes/Stg.h:318,
[ 4466s]
[ 4466s] from rts/StgCRun.c:45:0: error:
[ 4466s] rts/StgCRun.c: In function 'StgRun':
[ 4466s]
[ 4466s] includes/stg/Regs.h:444:46: error:
[ 4466s] error: 'MainCapability' undeclared (first use in this function); did you mean 'markCapability'?
[ 4466s] 444 | #define BaseReg (&((struct PartCapability_ *)MainCapability)->r)
[ 4466s] | ^~~~~~~~~~~~~~
[ 4466s] |
[ 4466s] 444 | #define BaseReg (&((struct PartCapability_ *)MainCapability)->r)
[ 4466s] | ^
[ 4466s]
[ 4466s] includes/stg/Regs.h:161:14: error:
[ 4466s] note: in expansion of macro 'BaseReg'
[ 4466s] 161 | # define R1 (BaseReg->rR1)
[ 4466s] | ^~~~~~~
[ 4466s] |
[ 4466s] 161 | # define R1 (BaseReg->rR1)
[ 4466s] | ^
[ 4466s]
[ 4466s] rts/StgCRun.c:83:27: error:
[ 4466s] note: in expansion of macro 'R1'
[ 4466s] 83 | return (StgRegTable *)R1.p;
[ 4466s] | ^~
[ 4466s] |
[ 4466s] 83 | return (StgRegTable *)R1.p;
[ 4466s] | ^
[ 4466s]
[ 4466s] includes/stg/Regs.h:444:46: error:
[ 4466s] note: each undeclared identifier is reported only once for each function it appears in
[ 4466s] 444 | #define BaseReg (&((struct PartCapability_ *)MainCapability)->r)
[ 4466s] | ^~~~~~~~~~~~~~
[ 4466s] |
[ 4466s] 444 | #define BaseReg (&((struct PartCapability_ *)MainCapability)->r)
[ 4466s] | ^
[ 4466s]
[ 4466s] includes/stg/Regs.h:161:14: error:
[ 4466s] note: in expansion of macro 'BaseReg'
[ 4466s] 161 | # define R1 (BaseReg->rR1)
[ 4466s] | ^~~~~~~
[ 4466s] |
[ 4466s] 161 | # define R1 (BaseReg->rR1)
[ 4466s] | ^
[ 4466s]
[ 4466s] rts/StgCRun.c:83:27: error:
[ 4466s] note: in expansion of macro 'R1'
[ 4466s] 83 | return (StgRegTable *)R1.p;
[ 4466s] | ^~
[ 4466s] |
[ 4466s] 83 | return (StgRegTable *)R1.p;
[ 4466s] | ^
[ 4466s] `cc' failed in phase `C Compiler'. (Exit code: 1)
[ 4466s] make[1]: *** [rts/ghc.mk:322: rts/dist/build/StgCRun.thr_o] Error 1
[ 4466s] make[1]: *** Waiting for unfinished jobs....
[ 4466s] make: *** [Makefile:128: all] Error 2
[ 4466s] error: Bad exit status from /var/tmp/rpm-tmp.J0wvxD (%build)
```
## Steps to reproduce
```
./configure
./make
```
## Expected behaviour
build ghc
## Environment
s390x
* GHC version used:
for bootstrapping 8.8.3
Optional:
* Operating System: openSUSE Tumbleweed zSystems
* System Architecture: s390x8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17956GHC 8.10.1 bundles an older version of text than 8.8.32020-10-06T15:00:32ZRyan ScottGHC 8.10.1 bundles an older version of text than 8.8.3```
$ /opt/ghc/8.8.3/bin/ghc-pkg list
/opt/ghc/8.8.3/lib/ghc-8.8.3/package.conf.d
...
text-1.2.4.0
...
$ ./ghc-8.10.1/bin/ghc-pkg list
/home/rgscott/Software/ghc-8.10.1/lib/ghc-8.10.1/package.conf.d
...
text-1.2.3.2
...```
$ /opt/ghc/8.8.3/bin/ghc-pkg list
/opt/ghc/8.8.3/lib/ghc-8.8.3/package.conf.d
...
text-1.2.4.0
...
$ ./ghc-8.10.1/bin/ghc-pkg list
/home/rgscott/Software/ghc-8.10.1/lib/ghc-8.10.1/package.conf.d
...
text-1.2.3.2
...
```
I doubt this was intended.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17693Improve and document atomicModifyMutVar2#2023-02-20T09:32:37ZSimon Peyton JonesImprove and document atomicModifyMutVar2#The primop `atomicModifyMutVar2#` is ill-documented, and its type
is extremely odd. Its declared type (in `primops.txt.pp` is
```
MutVar# s a -> (a -> c) -> State# s -> (# State# s, a, c #)
```
but that's a lie. Its real type is mor...The primop `atomicModifyMutVar2#` is ill-documented, and its type
is extremely odd. Its declared type (in `primops.txt.pp` is
```
MutVar# s a -> (a -> c) -> State# s -> (# State# s, a, c #)
```
but that's a lie. Its real type is more like this
```
MutVar# s a -> (a -> (a,b)) -> State# s -> (# State# s, a, (a, b) #)
```
And there is other tricky and entirely un-documented stuff about it. It all comes from an accepted [GHC Proposal 149: replace atomicModifyMutVar# primop](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0149-atomicModifyMutVar.rst), but much is unclear about it (to me anyway).
These topics are discussed in [this email thread](https://mail.haskell.org/pipermail/ghc-devs/2019-October/018223.html).
The thread ends up saying: I propose:
* To give `atomicModifyMutVar2#` its proper type, with a pair, as in the proposal.
* To do that, fiddle with `genprimopcode`, to allow it to parse tuples as well as unboxed tuples; not hard.
* This would disallow all this stuff about “any type that has a first field looking like a”, restricting to pairs alone. This didn’t form part of the proposal, and was never documented.
* Add a bit more clarity to the documentation, so it’d clear what must be forced.
This ticket is to record this task.
I've even done quite a bit of the work: see branch `wip/T17693`.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17660Performance regression in bytestring from 8.8 to 8.102021-07-14T16:17:36ZSimon JakobiPerformance regression in bytestring from 8.8 to 8.10## Summary
Many of the benchmarks in `bytestring`'s `bench-bytestring-builder` benchmark suite run much slower with 8.10.1-alpha2 than with 8.8.
Here are the first lines of the benchmark diff (produced with [`criterion-compare`](https:...## Summary
Many of the benchmarks in `bytestring`'s `bench-bytestring-builder` benchmark suite run much slower with 8.10.1-alpha2 than with 8.8.
Here are the first lines of the benchmark diff (produced with [`criterion-compare`](https://github.com/bgamari/criterion-compare)), sorted by significance:
![image](/uploads/516ac79ca826aa9ee23bf8b2eb830f4e/image.png)
[Full diff](/uploads/5d96ce2cce29f7038379515e6bf3450a/comparison.html)
Some of the results may be noisy, but at that magnitude it shouldn't matter much.
I also benchmarked with HEAD (923a127205dd60147453f4420614efd1be29f070), and got even worse results, but that might have been because that `ghc` was built with `--flavour=Quick`.
Note that the `substrings/*` benchmarks measure [the `findSubstrings` function](https://github.com/haskell/bytestring/blob/95fe6bdf13c9cc86c1c880164f7844d61d989574/Data/ByteString.hs#L1416-L1435), which is deprecated. So the performance of the other benchmarks is actually more important.
## Steps to reproduce
1. Clone the branch from [this PR](https://github.com/haskell/bytestring/pull/196) which fixes building the benchmarks.
2. `cd bench`
3. `cabal -O2 run bench-bytestring-builder`
## Expected behavior
The performance of these benchmarks should be no worse with 8.10 than with 8.8.
## Environment
* GHC versions used: 8.8.1 and 8.10.1-alpha2, both from hvr's PPA.
* Operating System: Linux
* System Architecture: `x86_64`8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17634Hadrian's hadrian.settings autocompletion returns far too many results2020-01-21T14:16:37ZBen GamariHadrian's hadrian.settings autocompletion returns far too many resultsCurrently `hadrian autocomplete --complete-setting=stage1.` will return over 500 keys since it returns every possible completion matching the prefix `stage1.`. This is not particularly helpful, akin to `ls /<tab>` listing the entire cont...Currently `hadrian autocomplete --complete-setting=stage1.` will return over 500 keys since it returns every possible completion matching the prefix `stage1.`. This is not particularly helpful, akin to `ls /<tab>` listing the entire contents of your filesystem.
It should rather only complete until the next dot (unless the match is unique).8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17583No -pgmcxx option to correspond with -optcxx2022-07-11T23:15:09ZMerijn VerstraatenNo -pgmcxx option to correspond with -optcxx## Summary
GHC 8.10 now stores C++ compiler flags in its settings and supports `-optcxx` to pass other flags, however the configure script doesn't detect or let users specify which C++ compiler to use, and there is also no corresponding...## Summary
GHC 8.10 now stores C++ compiler flags in its settings and supports `-optcxx` to pass other flags, however the configure script doesn't detect or let users specify which C++ compiler to use, and there is also no corresponding `-pgmcxx` option to override the C++ compiler used.
Lacking this configure option and flag makes it more complicated to implement better C++ support in Cabal/cabal-install.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17563Validity check quantified constraints2021-11-17T21:20:04ZRichard Eisenbergrae@richarde.devValidity check quantified constraintsThis module is accepted:
```hs
{-# LANGUAGE QuantifiedConstraints #-}
module Bug2 where
blah :: (forall a. a b ~ a c) => b -> c
blah = undefined
```
But it shouldn't be: it uses `~` with neither `GADTs` nor `TypeFamilies` enabled.This module is accepted:
```hs
{-# LANGUAGE QuantifiedConstraints #-}
module Bug2 where
blah :: (forall a. a b ~ a c) => b -> c
blah = undefined
```
But it shouldn't be: it uses `~` with neither `GADTs` nor `TypeFamilies` enabled.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17508Alpine bindist segmentation faults2024-03-21T16:04:47ZBen GamariAlpine bindist segmentation faultsThe 8.10.1-alpha1 Alpine bindist appears to generate invalid code. For instance, https://gitlab.haskell.org/ghc/ghc/-/jobs/209099.
The crash appears to occur in GMP.The 8.10.1-alpha1 Alpine bindist appears to generate invalid code. For instance, https://gitlab.haskell.org/ghc/ghc/-/jobs/209099.
The crash appears to occur in GMP.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17483Yet another mysterious Windows failure2020-01-21T14:16:37ZBen GamariYet another mysterious Windows failureI am occasionally seeing Windows tests fail with errors of the form (for various tests):
```
Traceback (most recent call last):
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 973, in test_commo...I am occasionally seeing Windows tests fail with errors of the form (for various tests):
```
Traceback (most recent call last):
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 973, in test_common_work
do_test(name, way, func, args, files)
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 1071, in do_test
result = func(*[name,way] + args)
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 1199, in compile_fail
return do_compile( name, way, True, None, [], extra_hc_opts )
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 1252, in do_compile
expected_stderr_file = find_expected_file(name, 'stderr')
File "/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/driver/testlib.py", line 2353, in find_expected_file
if in_srcdir(f).exists():
File "/usr/lib/python3.7/pathlib.py", line 1329, in exists
self.stat()
File "/usr/lib/python3.7/pathlib.py", line 1151, in stat
return self._accessor.stat(self)
OSError: [Errno 0] Error: '/c/GitLabRunner/builds/pA2hwqzM/0/SkyWriter/ghc/testsuite/tests/typecheck/should_fail/tcfail161.stderr-mingw32'
```
Note the `Errno 0`; this is just bizarre given that `tcfail161.sterr-mingw32` doesn't even exist.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17317Compiling Network.AWS.SWF.Types.Product in amazonka-swf uses more than 4G of ...2021-03-29T09:26:04ZJohn KyCompiling Network.AWS.SWF.Types.Product in amazonka-swf uses more than 4G of memory on Ubuntu-18.04## Summary
Write a brief description of the issue.
## Steps to reproduce
This is reproducible in this project at the commit:
https://github.com/arbor/antiope/commit/e3d7841912052c8a48fda0685b1ab41384e6faa9
Using the command:
```
ca...## Summary
Write a brief description of the issue.
## Steps to reproduce
This is reproducible in this project at the commit:
https://github.com/arbor/antiope/commit/e3d7841912052c8a48fda0685b1ab41384e6faa9
Using the command:
```
cabal v2-build all $_BUILD_ENABLE_TESTS_FLAG $_BUILD_ENABLE_BENCHMARKS_FLAG -j1
```
As shown in this failed Circle CI build:
https://circleci.com/gh/arbor/antiope/998
## Expected behavior
It is expected that a single module should not take this much memory to compile. Previous versions of GHC did not have this problem.
## Environment
* GHC version used: `ghc-8.8.1`
```
$ uname -a
Darwin INTLKyMac.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
```8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17305Data family instances aren't eta-reduced correctly2020-12-14T13:50:30ZRyan ScottData family instances aren't eta-reduced correctly(I originally discovered this when debugging #17296/!1877, but this doesn't rely on !1877 to reproduce.)
Take this code:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
impo...(I originally discovered this when debugging #17296/!1877, but this doesn't rely on !1877 to reproduce.)
Take this code:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
import Language.Haskell.TH hiding (Type)
import System.IO
data family Foo a
data instance Foo :: Type -> Type where
MkFoo :: Foo a
$(do i <- reify ''Foo
runIO $ hPutStrLn stderr $ pprint i
pure [])
```
And compile it with a `devel2`-flavoured compiler. (I'm on commit d0924b153b093a925c9e721f2540f3dfd6c278ae.) You'll get the following panic:
```
$ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o, Bug.dyn_o )
Bug.hs:1:1: error:
Exception when trying to run compile-time code:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.9.0.20191003:
zipEqual: unequal lists:zipTyEnv
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Code: do i <- reify ''Foo
runIO $ hPutStrLn stderr $ pprint i
pure []
|
1 | {-# LANGUAGE GADTs #-}
| ^
```8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17290`ForeignPtr` should be strict in `ForeignPtrContents`2020-09-11T16:58:46Zedsko@edsko.net`ForeignPtr` should be strict in `ForeignPtrContents`Right now `ForeignPtr` is defined as
```haskell
data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents
data ForeignPtrContents
= PlainForeignPtr !(IORef Finalizers)
| MallocPtr (MutableByteArray# RealWorld) !(IORef Finalizers...Right now `ForeignPtr` is defined as
```haskell
data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents
data ForeignPtrContents
= PlainForeignPtr !(IORef Finalizers)
| MallocPtr (MutableByteArray# RealWorld) !(IORef Finalizers)
| PlainPtr (MutableByteArray# RealWorld)
```
`ForeignPtrContents` is strict in all its fields, but `ForeignPtr` is lazy in the `ForeignPtrContents`. That should probably not be the case (or, if it should, we should document why).8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17288Data race during RTS shutdown2020-01-21T14:17:18ZBen GamariData race during RTS shutdownWhile looking at !1603:
```
==================
==================
WARNING: ThreadSanitizer: data race (pid=4596)
Write of size 8 at 0x00000090d6e8 by thread T6 (mutexes: write M16):
#0 stat_endGC rts/Stats.c:400 (T10296b+0x0000007...While looking at !1603:
```
==================
==================
WARNING: ThreadSanitizer: data race (pid=4596)
Write of size 8 at 0x00000090d6e8 by thread T6 (mutexes: write M16):
#0 stat_endGC rts/Stats.c:400 (T10296b+0x000000734e22)
#1 GarbageCollect rts/sm/GC.c:883 (T10296b+0x00000074cacb)
#2 scheduleDoGC rts/Schedule.c:1810 (T10296b+0x00000072d5e5)
#3 schedule rts/Schedule.c:552 (T10296b+0x00000072e977)
#4 scheduleWorker rts/Schedule.c:2572 (T10296b+0x0000007316be)
#5 workerStart rts/Task.c:445 (T10296b+0x0000007382d5)
#6 <null> <null> (libtsan.so.0+0x000000028d5b)
Previous read of size 8 at 0x00000090d6e8 by main thread:
#0 stat_startExit rts/Stats.c:273 (T10296b+0x000000734663)
#1 hs_exit_ rts/RtsStartup.c:380 (T10296b+0x000000729719)
#2 shutdownHaskellAndExit rts/RtsStartup.c:562 (T10296b+0x000000729f65)
#3 hs_main rts/RtsMain.c:99 (T10296b+0x000000728d7c)
#4 main <null> (T10296b+0x000000412f71)
Location is global 'stats' of size 320 at 0x00000090d660 (T10296b+0x00000090d6e8)
Mutex M16 (0x0000009103c0) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x00000002c81e)
#1 initMutex rts/posix/OSThreads.c:170 (T10296b+0x00000075d2b7)
#2 initStorage rts/sm/Storage.c:148 (T10296b+0x0000007573fb)
#3 hs_init_ghc rts/RtsStartup.c:245 (T10296b+0x000000729b60)
#4 hs_main rts/RtsMain.c:57 (T10296b+0x000000728d0b)
#5 main <null> (T10296b+0x000000412f71)
Thread T6 (tid=4603, running) created by thread T4 at:
#0 pthread_create <null> (libtsan.so.0+0x00000002c010)
#1 createOSThread rts/posix/OSThreads.c:137 (T10296b+0x00000075d22f)
#2 startWorkerTask rts/Task.c:497 (T10296b+0x000000738cea)
#3 releaseCapability_ rts/Capability.c:568 (T10296b+0x000000722cf7)
#4 suspendThread rts/Schedule.c:2420 (T10296b+0x000000730ea4)
#5 <null> <null> (T10296b+0x00000068bf11)
#6 scheduleWorker rts/Schedule.c:2572 (T10296b+0x0000007316be)
#7 workerStart rts/Task.c:445 (T10296b+0x0000007382d5)
#8 <null> <null> (libtsan.so.0+0x000000028d5b)
SUMMARY: ThreadSanitizer: data race rts/Stats.c:400 in stat_endGC
```8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17287Hadrian rebuilds all RTS dependency files when even a single file is changed2020-01-21T14:58:51ZBen GamariHadrian rebuilds all RTS dependency files when even a single file is changedRunning `hadrian/build.cabal.sh`, then touching a RTS source file (e.g. `rts/sm/GC.c`), then running `hadrian/build.cabal.sh` again results in the `FindCDependencies` jobs being rebuilt for all RTS source files. This is unnecessary.Running `hadrian/build.cabal.sh`, then touching a RTS source file (e.g. `rts/sm/GC.c`), then running `hadrian/build.cabal.sh` again results in the `FindCDependencies` jobs being rebuilt for all RTS source files. This is unnecessary.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17282Data race in compact_gc2020-01-21T14:17:18ZBen GamariData race in compact_gcWhile looking at !1603 I found the following data race triggered by the `compact_gc` test in the `threaded2` way:
```
==================
WARNING: ThreadSanitizer: data race (pid=29004)
Atomic read of size 2 at 0x7ee5c5700168 by main th...While looking at !1603 I found the following data race triggered by the `compact_gc` test in the `threaded2` way:
```
==================
WARNING: ThreadSanitizer: data race (pid=29004)
Atomic read of size 2 at 0x7ee5c5700168 by main thread (mutexes: write M16, write M28):
#0 __tsan_atomic16_load <null> (libtsan.so.0+0x000000060eec)
#1 evacuate rts/sm/Evac.c:637 (compact_gc+0x000000411982)
#2 evacuate_hash_entry rts/sm/Scav.c:165 (compact_gc+0x00000087453e)
#3 mapHashTable rts/Hash.c:394 (compact_gc+0x000000845e27)
#4 scavenge_compact rts/sm/Scav.c:182 (compact_gc+0x000000875037)
#5 scavenge_one rts/sm/Scav.c:1551 (compact_gc+0x000000875037)
#6 scavenge_large rts/sm/Scav.c:2008 (compact_gc+0x000000876afa)
#7 scavenge_find_work rts/sm/Scav.c:2068 (compact_gc+0x000000876afa)
#8 scavenge_loop rts/sm/Scav.c:2137 (compact_gc+0x000000876afa)
#9 scavenge_until_all_done rts/sm/GC.c:1112 (compact_gc+0x00000086a4fb)
#10 GarbageCollect rts/sm/GC.c:438 (compact_gc+0x00000086bc31)
#11 scheduleDoGC rts/Schedule.c:1814 (compact_gc+0x00000084db15)
#12 schedule rts/Schedule.c:552 (compact_gc+0x00000084eea7)
#13 scheduleWaitThread rts/Schedule.c:2559 (compact_gc+0x000000851b8d)
#14 rts_evalLazyIO rts/RtsAPI.c:530 (compact_gc+0x0000008991d1)
#15 hs_main rts/RtsMain.c:72 (compact_gc+0x000000849215)
#16 main <null> (compact_gc+0x000000414a41)
Previous write of size 8 at 0x7ee5c5700168 by thread T6:
#0 mmap <null> (libtsan.so.0+0x00000005d920)
#1 my_mmap rts/posix/OSMem.c:240 (compact_gc+0x00000087cae2)
#2 osCommitMemory rts/posix/OSMem.c:599 (compact_gc+0x00000087d345)
#3 getFreshMBlocks rts/sm/MBlock.c:205 (compact_gc+0x00000086fef3)
#4 getCommittedMBlocks rts/sm/MBlock.c:216 (compact_gc+0x00000086fef3)
#5 getMBlocks rts/sm/MBlock.c:580 (compact_gc+0x000000870218)
#6 alloc_mega_group rts/sm/BlockAlloc.c:378 (compact_gc+0x000000868be1)
#7 allocGroupOnNode rts/sm/BlockAlloc.c:429 (compact_gc+0x00000086970d)
#8 allocLargeChunkOnNode rts/sm/BlockAlloc.c:506 (compact_gc+0x000000869e32)
#9 allocBlocks_sync rts/sm/GCUtils.c:59 (compact_gc+0x00000086f8ee)
#10 alloc_todo_block rts/sm/GCUtils.c:329 (compact_gc+0x00000086f8ee)
#11 todo_block_full rts/sm/GCUtils.c:298 (compact_gc+0x00000086fc5d)
#12 alloc_for_copy rts/sm/Evac.c:80 (compact_gc+0x00000040e3f5)
#13 copy_tag_nolock rts/sm/Evac.c:157 (compact_gc+0x00000040e3f5)
#14 evacuate rts/sm/Evac.c:706 (compact_gc+0x00000040e3f5)
#15 scavenge_block rts/sm/Scav.c:496 (compact_gc+0x000000409024)
#16 scavenge_find_work rts/sm/Scav.c:2061 (compact_gc+0x0000008768e7)
#17 scavenge_loop rts/sm/Scav.c:2137 (compact_gc+0x0000008768e7)
#18 scavenge_until_all_done rts/sm/GC.c:1112 (compact_gc+0x00000086a4fb)
#19 gcWorkerThread rts/sm/GC.c:1185 (compact_gc+0x00000086e368)
#20 yieldCapability rts/Capability.c:904 (compact_gc+0x000000843a65)
#21 scheduleYield rts/Schedule.c:681 (compact_gc+0x00000084f452)
#22 schedule rts/Schedule.c:295 (compact_gc+0x00000084f452)
#23 scheduleWorker rts/Schedule.c:2576 (compact_gc+0x000000851bfe)
#24 workerStart rts/Task.c:445 (compact_gc+0x000000858815)
#25 <null> <null> (libtsan.so.0+0x000000028d5b)
Mutex M16 (0x000000a530c0) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x00000002c81e)
#1 initMutex rts/posix/OSThreads.c:170 (compact_gc+0x00000087d777)
#2 initStorage rts/sm/Storage.c:148 (compact_gc+0x00000087791b)
#3 hs_init_ghc rts/RtsStartup.c:245 (compact_gc+0x00000084a040)
#4 hs_main rts/RtsMain.c:57 (compact_gc+0x0000008491eb)
#5 main <null> (compact_gc+0x000000414a41)
Mutex M28 (0x000000a52320) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x00000002c81e)
#1 initMutex rts/posix/OSThreads.c:170 (compact_gc+0x00000087d777)
#2 initStablePtrTable rts/StablePtr.c:162 (compact_gc+0x0000008538c1)
#3 initStablePtrTable rts/StablePtr.c:155 (compact_gc+0x0000008539b4)
#4 hs_init_ghc rts/RtsStartup.c:248 (compact_gc+0x00000084a045)
#5 hs_main rts/RtsMain.c:57 (compact_gc+0x0000008491eb)
#6 main <null> (compact_gc+0x000000414a41)
Thread T6 (tid=29011, running) created by thread T4 at:
#0 pthread_create <null> (libtsan.so.0+0x00000002c010)
#1 createOSThread rts/posix/OSThreads.c:137 (compact_gc+0x00000087d6ef)
#2 startWorkerTask rts/Task.c:497 (compact_gc+0x00000085922a)
#3 releaseCapability_ rts/Capability.c:567 (compact_gc+0x000000843197)
#4 suspendThread rts/Schedule.c:2424 (compact_gc+0x0000008513e4)
#5 <null> <null> (compact_gc+0x0000007ad139)
#6 scheduleWorker rts/Schedule.c:2576 (compact_gc+0x000000851bfe)
#7 workerStart rts/Task.c:445 (compact_gc+0x000000858815)
#8 <null> <null> (libtsan.so.0+0x000000028d5b)
SUMMARY: ThreadSanitizer: data race (/nix/store/c7hj2bk4aqgpb3q0h5xhq7lag0lq3jm7-gcc-7.4.0-lib/lib/libtsan.so.0+0x60eec) in __tsan_atomic16_load
```
The load in question in `evacuate` is:
```c
StgClosure *e = (StgClosure*)UN_FORWARDING_PTR(info);
RELAXED_STORE(p, TAG_CLOSURE(tag,e));
if (gen_no < gct->evac_gen_no) { // optimisation
if (RELAXED_LOAD(&Bdescr((P_)e)->gen_no) // <===== this, I think
< gct->evac_gen_no) {
gct->failed_to_evac = true;
TICK_GC_FAILED_PROMOTION();
}
}
return;
```
Given that I only see this in `compact_gc`, I suspect this is a bug in the CNF compactor which fails to initialize block descriptors correctly.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17280Compact normal form block allocation can race with GC initialization2020-01-21T14:17:17ZBen GamariCompact normal form block allocation can race with GC initializationWhile looking at !1603 I stumbled upon the following data race:
```
==================
WARNING: ThreadSanitizer: data race (pid=9105)
Atomic read of size 8 at 0x7b5800000048 by thread T6:
#0 __tsan_atomic64_load <null> (libtsan.so....While looking at !1603 I stumbled upon the following data race:
```
==================
WARNING: ThreadSanitizer: data race (pid=9105)
Atomic read of size 8 at 0x7b5800000048 by thread T6:
#0 __tsan_atomic64_load <null> (libtsan.so.0+0x00000006130c)
#1 calcNeeded rts/sm/Storage.c:1294 (compact_mutable+0x00000075c945)
#2 scheduleDoGC rts/Schedule.c:1549 (compact_mutable+0x00000072f361)
#3 schedule rts/Schedule.c:255 (compact_mutable+0x000000731722)
#4 scheduleWorker rts/Schedule.c:2576 (compact_mutable+0x000000733dce)
#5 workerStart rts/Task.c:445 (compact_mutable+0x00000073a9e5)
#6 <null> <null> (libtsan.so.0+0x000000028d5b)
Previous write of size 8 at 0x7b5800000048 by main thread (mutexes: write M16):
#0 compactAllocateBlockInternal rts/sm/CNF.c:209 (compact_mutable+0x000000780661)
#1 compactNew rts/sm/CNF.c:372 (compact_mutable+0x000000780965)
#2 stg_compactNewzh <null> (compact_mutable+0x000000761ceb)
#3 scheduleWaitThread rts/Schedule.c:2559 (compact_mutable+0x000000733d5d)
#4 rts_evalLazyIO rts/RtsAPI.c:530 (compact_mutable+0x00000077b681)
#5 hs_main rts/RtsMain.c:72 (compact_mutable+0x00000072b3e5)
#6 main <null> (compact_mutable+0x000000412da5)
Location is heap block of size 768 at 0x7b5800000000 allocated by main thread:
#0 malloc <null> (libtsan.so.0+0x00000002b251)
#1 stgMallocBytes rts/RtsUtils.c:64 (compact_mutable+0x00000072c63b)
#2 initStorage rts/sm/Storage.c:154 (compact_mutable+0x000000759b40)
#3 hs_init_ghc rts/RtsStartup.c:245 (compact_mutable+0x00000072c210)
#4 hs_main rts/RtsMain.c:57 (compact_mutable+0x00000072b3bb)
#5 main <null> (compact_mutable+0x000000412da5)
Mutex M16 (0x0000009127c0) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x00000002c81e)
#1 initMutex rts/posix/OSThreads.c:170 (compact_mutable+0x00000075f937)
#2 initStorage rts/sm/Storage.c:148 (compact_mutable+0x000000759b0b)
#3 hs_init_ghc rts/RtsStartup.c:245 (compact_mutable+0x00000072c210)
#4 hs_main rts/RtsMain.c:57 (compact_mutable+0x00000072b3bb)
#5 main <null> (compact_mutable+0x000000412da5)
Thread T6 (tid=9112, running) created by thread T5 at:
#0 pthread_create <null> (libtsan.so.0+0x00000002c010)
#1 createOSThread rts/posix/OSThreads.c:137 (compact_mutable+0x00000075f8af)
#2 startWorkerTask rts/Task.c:497 (compact_mutable+0x00000073b3fa)
#3 releaseCapability_ rts/Capability.c:567 (compact_mutable+0x000000725367)
#4 suspendThread rts/Schedule.c:2424 (compact_mutable+0x0000007335b4)
#5 <null> <null> (compact_mutable+0x00000068e541)
#6 scheduleWorker rts/Schedule.c:2576 (compact_mutable+0x000000733dce)
#7 workerStart rts/Task.c:445 (compact_mutable+0x00000073a9e5)
#8 <null> <null> (libtsan.so.0+0x000000028d5b)
SUMMARY: ThreadSanitizer: data race (/nix/store/c7hj2bk4aqgpb3q0h5xhq7lag0lq3jm7-gcc-7.4.0-lib/lib/libtsan.so.0+0x6130c) in __tsan_atomic64_load
```
`compactAllocateBlockInternal` updates `generation->n_compact_blocks` while holding `SM_LOCK` yet `calcNeeded` doesn't bother to take `SM_LOCK` itself.
Arguably this isn't the end of the world resulting in only a slight change in GC timing.8.10.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17277Inconsistent behaviour of StandaloneKindSignatures with type families which a...2020-04-15T15:28:19Zsheafsam.derbyshire@gmail.comInconsistent behaviour of StandaloneKindSignatures with type families which are not given standalone kind signaturesTurning on `StandaloneKindSignatures` stops the following program from typechecking:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE S...Turning on `StandaloneKindSignatures` stops the following program from typechecking:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE TypeFamilies #-}
data AB = A | B
data SAB (ab :: AB) where
SA :: SAB 'A
SB :: SAB 'B
--type SingAB :: forall (ab :: AB) -> SAB ab
type family SingAB (ab :: AB) :: SAB ab where
SingAB A = 'SA
SingAB B = 'SB
```
```
saks.hs:15:12: error:
* Expected kind `SAB ab', but 'SA has kind `SAB 'A'
* In the type 'SA
In the type family declaration for `SingAB'
|
15 | SingAB A = 'SA
|
```
Uncommenting the standalone kind signature allows the program to typecheck.
When removing the equations for the type family `SingAB`, with or without the standalone kind signature, one has:
```haskell
> :set -fprint-explicit-foralls -fprint-explicit-kinds
> :kind! SingAB
SingAB :: forall (ab :: AB) -> SAB ab
= SingAB
```
So I'm not sure why the equations fail to typecheck without the standalone kind signature.
Similar behaviour also happens for the invisible equivalent:
```haskell
--type SingAB2 :: forall (ab :: AB). SAB ab
type family SingAB2 :: SAB ab where
SingAB2 = ( 'SA :: SAB 'A )
SingAB2 = ( 'SB :: SAB 'B )
```
```
saks.hs:21:15: error:
* Expected kind `SAB ab', but 'SA :: SAB 'A has kind `SAB 'A'
* In the type `('SA :: SAB 'A)'
In the type family declaration for `SingAB2'
|
21 | SingAB2 = ( 'SA :: SAB 'A )
| ^^^
```
Ditto for passing the type explicitly:
```haskell
--type SingAB3 :: forall (ab :: AB). Proxy ab -> SAB ab
type family SingAB3 ( px :: Proxy ab ) :: SAB ab where
SingAB3 ( _ :: Proxy 'A ) = 'SA
SingAB3 ( _ :: Proxy 'B ) = 'SB
```
With `StandaloneKindSignatures` enabled, this causes the following error:
```
saks.hs:28:13: error:
* Expected kind `Proxy @{AB} ab',
but `_ :: Proxy 'A' has kind `Proxy @{AB} 'A'
* In the first argument of `SingAB3', namely `(_ :: Proxy 'A)'
In the type family declaration for `SingAB3'
|
28 | SingAB3 ( _ :: Proxy 'A ) = 'SA
| ^^^^^^^
```
Either turning off `StandaloneKindSignatures`, or uncommenting the standalone kind signature, allows the program to typecheck.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17274Fuse "reverse"2020-01-21T14:17:18ZTobias DeckingFuse "reverse"Going through `GHC/List.hs` in `base`, I've noticed that `reverse` does not have any fusion rules at all.
Although the version of the language report is a good consumer, it is currently unused, AFAIK because of previous versions of ghc h...Going through `GHC/List.hs` in `base`, I've noticed that `reverse` does not have any fusion rules at all.
Although the version of the language report is a good consumer, it is currently unused, AFAIK because of previous versions of ghc having
difficulities optimizing `foldl`. This changed however, and it was trivial to make it a good producer aswell.
Before i submit a patch however, I want to have this issue recorded and give everyone a chance to voice anything related.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17269T13615 fails in unrelated MRs2020-01-21T14:15:36ZSebastian GrafT13615 fails in unrelated MRsCurrently, `T13615` consistently fails for both !1828 (which fixes a bug in the rule matcher) and !1830 (which just adds some test cases and doesn't touch the compiler *at all*). [Example job 1](https://gitlab.haskell.org/ghc/ghc/-/jobs/...Currently, `T13615` consistently fails for both !1828 (which fixes a bug in the rule matcher) and !1830 (which just adds some test cases and doesn't touch the compiler *at all*). [Example job 1](https://gitlab.haskell.org/ghc/ghc/-/jobs/166384), [Example job 2](https://gitlab.haskell.org/ghc/ghc/-/jobs/166305).
- It only affects validate-x86_64-linux-deb9-debug, probably because the particular configuration isn't run in the other CI flavors
- In both cases the error is
```
Wrong exit code for T13615(threaded1)(expected 0 , actual 139 )
Stderr ( T13615 ):
Segmentation fault (core dumped)
```
Not sure what's happening there.8.10.2