GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-10-03T15:53:24Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/17260Link to Haddocks for Language.Haskell.TH is broken2023-10-03T15:53:24ZadamLink to Haddocks for Language.Haskell.TH is brokenThe link to the haddocks in the [users guide][1] is broken: <https://downloads.haskell.org/ghc/latest/docs/html/libraries/template-haskell-@LIBRARY_template_haskell_VERSION@/Haddock%20reference%20documentation%20%3CLanguage-Haskell-TH.ht...The link to the haddocks in the [users guide][1] is broken: <https://downloads.haskell.org/ghc/latest/docs/html/libraries/template-haskell-@LIBRARY_template_haskell_VERSION@/Haddock%20reference%20documentation%20%3CLanguage-Haskell-TH.html#v:%3E>
[1]: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#template-haskell8.8.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17457Release tracking ticket for 8.8.22022-02-11T16:59:23ZBen GamariRelease tracking ticket for 8.8.2> This is the template to be used to create release tracking tickets. Copy this into a new issue and fill in the TODOs.
This is the release checklist for the TODO milestone. See #16816 for the template that this was derived from.
# Pr...> This is the template to be used to create release tracking tickets. Copy this into a new issue and fill in the TODOs.
This is the release checklist for the TODO milestone. See #16816 for the template that this was derived from.
# Pre-release checklist
* [x] Remove the release notes for the previous release (e.g. `docs/users_guide/8.6.*-notes.rst`)
* [x] Make release branch (e.g. `ghc-8.8`)
* [x] Make post-release branch (e.g. `ghc-8.9-start`)
* [ ] Submodules on released tags (produced using [this script](https://gitlab.haskell.org/bgamari/ghc-utils/blob/master/rel-eng/submod-release-summary.py)):
* [ ] `libraries/Cabal`: *todo* (on `Cabal-v3.0.0.0-rc3`)
* [x] `libraries/Win32`: version 2.6.1.0
* [x] `libraries/array`: version 0.5.4.0
* [x] `libraries/binary`: version 0.8.7.0
* [x] `libraries/bytestring`: version 0.10.10.0-ghc1
* [x] `libraries/containers`: version 0.6.2.1
* [x] `libraries/deepseq`: version 1.4.4.0-r1
* [x] `libraries/directory`: version 1.3.4.0
* [x] `libraries/filepath`: version 1.4.2.1-ghc1
* [x] `libraries/haskeline`: version 0.7.5.0-ghc1
* [x] `libraries/mtl`: version 2.2.2
* [x] `libraries/parsec`: version 3.1.14.0
* [x] `libraries/pretty`: version 1.1.3.6
* [x] `libraries/process`: version 1.6.7.0
* [x] `libraries/stm`: version 2.5.0.0-ghc1
* [x] `libraries/terminfo`: version 0.4.1.4
* [x] `libraries/text`: version 1.2.4.0
* [x] `libraries/time`: version 1.9.3
* [x] `libraries/transformers`: version 0.5.6.2
* [x] `libraries/unix`: version 2.7.2.2-r3
* [x] `libraries/xhtml`: version 3000.2.2.1
* [ ] `utils/haddock`: *todo* (on `haddock-library-1.4.5-release-471-ge6ca100973`)
* [ ] `utils/hsc2hs`: *todo* (on `v0.68.4-21-gefb556c`)
* [x] Non-released submodules up-to-date:
* [x] `nofib`
* [x] `libffi-tarballs`
* [x] `libraries/integer-gmp/gmp/gmp-tarballs`
* [x] Release notes (`docs/users_guide/x.y.z-notes.rst`) written
* [x] Release notes linked in `docs/users_guide/index.rst`
* [x] `autoconf` scripts [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-the-tree)
* [x] `LlvmVersion` in `configure.ac` is targetting intended LLVM version
* [x] Release notes mentions LLVM version requirement
* [x] `llvm-targets` file [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-the-tree)
* [x] Changelogs updated (these can be checked using `.gitlab/linters/check-changelogs.sh`):
* [x] `libraries/ghc-prim`
* [x] `libraries/integer-gmp`
* [x] `libraries/integer-simple`
* [x] `libraries/hpc`
* [x] `libraries/base`
* [x] `libraries/ghc-boot-th`
* [x] `libraries/ghc-boot`
* [x] Verify that the ~"backport needed" label has no more issues/merge requests needing backport
* [ ] Verify that all CI builds are green before moving to *release checklist*
# Release checklist
* [ ] [Make tag](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#tagging-the-release)
* [ ] Wait until builds finish
* [ ] Fetch release artifacts TODO: documentation
* [ ] Sign and push release artifacts to `downloads.haskell.org` [TODO: documentation]
* [ ] Release/revise GHC-maintained libraries on Hackage [TODO: documentation]
* [ ] `libraries/base`
* [ ] `libraries/ghc-prim`
* [ ] `libraries/array`
* [ ] `libraries/stm`
* [ ] `libraries/ghc-heap`
* [ ] `libraries/ghc-compact`
* [ ] `libraries/ghc-boot`
* [ ] `libraries/ghc-boot-th`
* [ ] `libraries/hpc`
* [ ] `libraries/libiserv`
* [ ] `libraries/template-haskell`
* [ ] `libraries/integer-gmp`
* [ ] `libraries/integer-simple`
* [ ] Update ghc/homepage>:
* [ ] Write download page (see ghc/homepage>)
* [ ] Add news item to [`index.html`](https://gitlab.haskell.org/ghc/homepage/blob/master/index.shtml)
* [ ] Add link to [`download.shtml`](https://gitlab.haskell.org/ghc/homepage/blob/master/download.shtml)
* [ ] Look over changes locally
* [ ] Add release announcement to [GHC blog](https://gitlab.haskell.org/ghc/homepage/tree/master/blog)
* [ ] Push changes to `master`
* [ ] Announce on: `GHC developers <ghc-devs@haskell.org>, GHC Users <glasgow-haskell-users@haskell.org>, Haskell Cafe <haskell-cafe@haskell.org>`
* [ ] Announce on: [Haskell Discourse](https://discourse.haskell.org/), [/r/haskell](https://reddit.com/r/haskell), [Twitter](https://twitter.com/)
* [ ] Update `latest` symlink on `downloads.haskell.org`
* [ ] Ensure that the [Migration](https://gitlab.haskell.org/ghc/ghc/wikis/migration/) page is up-to-date
# Post-release checklist
* [ ] Update the Wiki [status page](https://gitlab.haskell.org/ghc/ghc/wikis/status)
* [ ] Update the [language pragma history](https://gitlab.haskell.org/ghc/ghc/wikis/language-pragma-history)
* [ ] Mark milestone as *closed*
* [ ] Update the [VersionHistory](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/libraries/version-history) wiki page
* [ ] Set `RELEASE=NO`8.8.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16912LLVM version check for GHC 8.8.1-alpha22021-06-10T14:45:04ZStefan Schulze FrielinghausLLVM version check for GHC 8.8.1-alpha2While giving 8.8.1-alpha2 a try and using the LLVM backend I receive a lot of warnings of the form
```
You are using an unsupported version of LLVM! ...While giving 8.8.1-alpha2 a try and using the LLVM backend I receive a lot of warnings of the form
```
You are using an unsupported version of LLVM!
Currently only 7 is supported.
We will try though...
```
However, I'm using version 7:
```
$ llc --version
LLVM (http://llvm.org/):
LLVM version 7.0.1
...
$ opt --version
LLVM (http://llvm.org/):
LLVM version 7.0.1
...
```
I guess the problematic part is the following of file `compiler/llvmGen/LlvmCodeGen.hs`
```
debugTraceMsg dflags 2
(text "Using LLVM version:" <+> text (show ver))
let doWarn = wopt Opt_WarnUnsupportedLlvmVersion dflags
when (ver /= supportedLlvmVersion && doWarn) $
putMsg dflags (text "You are using an unsupported version of LLVM!"
$+$ text ("Currently only " ++
llvmVersionStr supportedLlvmVersion ++
" is supported.")
$+$ text "We will try though...")
```
In my case `ver` equals `LlvmVersion 7` and `supportedLlvmVersion` equals `LlvmVersionOld 7 0`. Thus `ver /= supportedLlvmVersion` evaluates to `False` which is Ok but it shouldn't ;-)
Used GHC version e20fe447e1930fcb8d019904d1b26b4312a835228.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17439Segfault during GC with -ffull-laziness and unsafeCoerce#2021-04-12T18:04:26ZLeon P Smithleon.p.smith@gmail.comSegfault during GC with -ffull-laziness and unsafeCoerce### Summary
The sample program segfaults during the call to `performGC`
## Steps to reproduce
Compile [Main.hs](/uploads/ed1ba0432684bd05da3b0e2986e93bcc/Main.hs), and run it. Unfortunately there are some sensitivities when using `per...## Summary
The sample program segfaults during the call to `performGC`
## Steps to reproduce
Compile [Main.hs](/uploads/ed1ba0432684bd05da3b0e2986e93bcc/Main.hs), and run it. Unfortunately there are some sensitivities when using `performMinorGC` that aren't fully understood yet; but an updated version of [Main.hs](https://gitlab.haskell.org/ghc/ghc/uploads/14b0bf94e89e72a5240ba2fe571f12c1/Main.hs) uses `performMajorGC` instead and removes the calls to `getEnvironment`.
## Environment
* GHC version used: 8.4.3
* Operating System: NixOS
* System Architecture: x648.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17319Can not load winpthread.dll (ghci)2021-02-26T14:06:16ZIgor HnízdoCan not load winpthread.dll (ghci)## Summary
After a clean install, launching the ghc interpret:
```
C:\WINDOWS\system32>ghci
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
ghc.exe: Could not load `libwinpthread-1.dll'. Reason: addDLL: libwinpthread-1.dl...## Summary
After a clean install, launching the ghc interpret:
```
C:\WINDOWS\system32>ghci
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
ghc.exe: Could not load `libwinpthread-1.dll'. Reason: addDLL: libwinpthread-1.dll or dependencies not loaded. (Win32 error 1392)
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-mingw32):
loadArchive "C:\\Program Files\\Haskell Platform\\8.6.5\\mingw\\x86_64-w64-mingw32\\lib\\libpthread.dll.a": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The archive is there.
## Environment
* GHC version used: 8.6.5
Optional:
* Operating System: Windows 10 1903
* System Architecture: 64bit8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/16775Don't zap naughty quantification candidates: error instead2020-12-15T12:32:56ZRichard Eisenbergrae@richarde.devDon't zap naughty quantification candidates: error insteadNote [Naughty quantification candidates] in TcMType describes a scenario like `forall arg. ... (alpha[tau] :: arg) ...`, where `alpha`, a unification variable, has a bound skolem in its type. If `alpha` is otherwise unconstrained, we sim...Note [Naughty quantification candidates] in TcMType describes a scenario like `forall arg. ... (alpha[tau] :: arg) ...`, where `alpha`, a unification variable, has a bound skolem in its type. If `alpha` is otherwise unconstrained, we simply don't know what to do with it. So, as the Note explains, we zap it to `Any`.
However, we recently decided not to `Any`-ify in type declarations. And I think we are wrong to `Any`-ify here, too. We should just error. If not, we risk having `Any` leak in error messages, and it seems a nice goal not to ever let users see `Any` (short of TH or reflection or other dastardly deeds).
The example is `partial-sigs/should_fail/T14040a`. You can find the program in question at the top of #14040. https://gitlab.haskell.org/ghc/ghc/issues/14040#note_168778 reports HEAD's error message. (The program and error message are all very intricate. Don't get distracted by reading them.) However, some of the wildcards in that error message have locally-bound types, meaning there is no hope for them, regardless of other errors about. In other work (some refactoring to be posted soon), I spotted that `tcHsPartialSigType` was missing out on the action in Note [Naughty quantification candidates] and so fixed the problem. This means that the error for that program now mentions `Any`.
Here is a simpler test case:
```
foo :: forall (f :: forall a (b :: a -> Type). b _). f _
foo = foo
```
Note that the type of the first `_` must be `a`, which is locally quantified. In HEAD, this program trips an assertion failure around the substitution invariant (and I have not investigated further). In my branch that duly checks partial signatures for naught quantification candidates, we get
```
• Expected kind ‘k -> *’, but ‘f’ has kind ‘k -> Any @*’
• In the type ‘f _’
In the type signature:
foo :: forall (f :: forall a (b :: a -> Type). b _). f _
```
This is correct enough, but there's `Any` in the error message. I think it would be much better just to reject the type signature a priori.
If I make the program correct (by wrapping the `f _` in a call to `Proxy`, I get
```
Scratch.hs:44:50: warning: [-Wpartial-type-signatures]
• Found type wildcard ‘_’ standing for ‘Any @a :: a’
Where: ‘a’ is a rigid type variable bound by
‘forall a (b :: a -> Type). b _’
at Scratch.hs:44:28
• In the first argument of ‘b’, namely ‘_’
In the kind ‘forall a (b :: a -> Type). b _’
In the type signature:
foo :: forall (f :: forall a (b :: a -> Type). b _). Proxy (f _)
|
44 | foo :: forall (f :: forall a (b :: a -> Type). b _). Proxy (f _)
| ^
Scratch.hs:44:63: warning: [-Wpartial-type-signatures]
• Found type wildcard ‘_’ standing for ‘_ :: k’
Where: ‘k’, ‘_’ are rigid type variables bound by
the inferred type of
foo :: Proxy
@{Any @Type} (f @Type @((->) @{'LiftedRep} @{'LiftedRep} k) _)
at Scratch.hs:45:1-9
• In the first argument of ‘f’, namely ‘_’
In the first argument of ‘Proxy’, namely ‘(f _)’
In the type ‘Proxy (f _)’
|
44 | foo :: forall (f :: forall a (b :: a -> Type). b _). Proxy (f _)
| ^
```
More `Any`s. No! Reject!
What think you (for any value of you)?8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/16916CPU burning loop when should be blocked on recv?2020-08-12T07:50:52ZIvan KasatenkoCPU burning loop when should be blocked on recv?## Summary
I have a pretty simple application that uses web sockets (websockets + wuss packages) to tunnel data. At the core there are two threads that read and write from the web socket. After some period of activity it seems to get st...## Summary
I have a pretty simple application that uses web sockets (websockets + wuss packages) to tunnel data. At the core there are two threads that read and write from the web socket. After some period of activity it seems to get stuck in a loop that consumes 100% CPU (1 CPU core) when it should rather be blocked on `recv`.
If you look at the `+RTS -Ds` output you would notice that IOManager thread constantly wakes up and goes to sleep, with the GC getting triggered from time to time. What's weird is that even though IOManager thread apparently does some work no other thread gets waken up to consume the results.
I have attached `+RTS -Ds`, `dtruss` and profile output (with <0.3% items filtered out).
[ds.txt](/uploads/aa6b31cdfd0dc34abb5f16656316c239/ds.txt)
[dtruss.txt](/uploads/939d0d85d4a74e738ce3455e9e8f1932/dtruss.txt)
[zaloopa-client-exe.prof](/uploads/5f75223c85715bfcad2a2766c953aef8/zaloopa-client-exe.prof)
## Steps to reproduce
Having `recv` and `send` going on at the same websocket.
## Expected behavior
Block with zero CPU usage.
## Environment
* GHC version used: 8.6.5 (Stack LTS-13.27), tried 8.4.4 (Stack LTS-12.26) with the same effect.
Optional:
* Operating System: macOS Mojave 10.14.5
* System Architecture: x648.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17312Potentially unnecessary warning about missing deriving strategies2020-07-17T19:06:27ZtaylorfausakPotentially unnecessary warning about missing deriving strategies## Summary
I'm not sure if this is a bug or not. I ran into it when compiling code using GHC 8.8.1 and `-Weverything`. I was surprised to find that `-Wmissing-deriving-strategies` fires even when there is no ambiguity about which derivi...## Summary
I'm not sure if this is a bug or not. I ran into it when compiling code using GHC 8.8.1 and `-Weverything`. I was surprised to find that `-Wmissing-deriving-strategies` fires even when there is no ambiguity about which deriving strategy should be used. In other words, with no language extensions enabled, (I think) `stock` is the only valid deriving strategy. Therefore I would not expect this warning to fire. I would expect this warning to fire if I had `GeneralizedNewtypeDeriving`, `DeriveAnyClass`, `DerivingStrategies`, or `DerivingVia` enabled.
## Steps to reproduce
``` sh
$ ghc -Wmissing-deriving-strategies -e 'data T = C deriving Eq'
```
```
<interactive>:0:12: warning: [-Wmissing-deriving-strategies]
No deriving strategy specified. Did you want stock, newtype, or anyclass?
Use DerivingStrategies to specify a strategy.
```
## Expected behavior
I expected no warning because the `deriving` clause is not ambiguous.
## Environment
* GHC version used: 8.8.1
Optional:
* Operating System: Windows 10
* System Architecture: x86_648.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17146build 8.8.1 with 8.8.1 fails with -DSTAGE=12020-05-07T07:42:34Zdonnbuild 8.8.1 with 8.8.1 fails with -DSTAGE=1## Summary
ghc-8.8.1 fails to build self, because with -DSTAGE=1 it can't get TAG_MASK from MachDeps.h
(ghc-8.6.3 works, but just because it doesn't pass the -DSTAGE=1 to gcc.)
## Steps to reproduce
Build and install 8.8.1. Use it t...## Summary
ghc-8.8.1 fails to build self, because with -DSTAGE=1 it can't get TAG_MASK from MachDeps.h
(ghc-8.6.3 works, but just because it doesn't pass the -DSTAGE=1 to gcc.)
## Steps to reproduce
Build and install 8.8.1. Use it to build 8.8.1 again from scratch.
## Expected behavior
Die on stage 1, compiler/parser/cutils.c TAG_MASK undefined in ClosureMacros.h
(I don't really expect that, since I'm sure this has been done numerous times with no problem, but it's what happened here, and the way it works - only 8.8.1 passes -Xpreprocessor '-DSTAGE=1' to gcc - has me quite baffled.)
Related to issue #16797
## Environment
8.8.1
Optional:
Haiku
Intel8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17414File read/write operations >= 2GiB fail on macOS with an "Invalid argument" e...2020-04-13T21:57:33ZLuite StegemanFile read/write operations >= 2GiB fail on macOS with an "Invalid argument" exception## Summary
File reads/writes bigger than 2GB result in an "Invalid argument" exception on macOS. Files bigger than 2GB still work, but individual read/write operations bigger than 2GB fail.
This was already reported for the `bytestring...## Summary
File reads/writes bigger than 2GB result in an "Invalid argument" exception on macOS. Files bigger than 2GB still work, but individual read/write operations bigger than 2GB fail.
This was already reported for the `bytestring` library, but the actual problem is in `base`. I didn't see an earlier report.
`bytestring` report: https://github.com/haskell/bytestring/issues/153
Python has a workaround for this issue and more discussion: https://bugs.python.org/issue24658
## Steps to reproduce
```
{-# LANGUAGE ScopedTypeVariables #-}
import Foreign.Ptr (Ptr)
import Foreign.Marshal.Alloc (mallocBytes, free)
import System.IO (hPutBuf, withBinaryFile, IOMode (WriteMode))
-- more than 2GiB
numBytes :: Int
numBytes = 2264375889
main :: IO ()
main = do
(ptr :: Ptr ()) <- mallocBytes numBytes
-- the next line produces the exception on macOS
withBinaryFile "test.out" WriteMode (\h -> hPutBuf h ptr numBytes)
free ptr
```
## Expected behavior
The `base` library provides operating system independent buffering and encoding functionality. I think it should work around operating system peculiarities and write all the data to the `test.out` file without throwing an excepion.
## Environment
Tested with GHC 8.6.5 on macOS 10.14.68.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17171`runghc` accepts invalid main program (for GHC 8.8.1)2020-03-22T17:02:46ZHerbert Valerio Riedelhvr@gnu.org`runghc` accepts invalid main program (for GHC 8.8.1)Consider the `Main` module
```
module Main () where main = putStrLn "The impossible happened"
```
which according to the Haskell Report does not constitute a valid Haskell Program (as it doesn't export the `main` entry point)
Compilin...Consider the `Main` module
```
module Main () where main = putStrLn "The impossible happened"
```
which according to the Haskell Report does not constitute a valid Haskell Program (as it doesn't export the `main` entry point)
Compiling this with `ghc --make` will rightly reject it with
```
Main.hs:1:1: error:
The IO action ‘main’ is not exported by module ‘Main’
|
1 | module Main () where main = putStrLn "The impossible happened"
| ^
```
However, `runghc Main.hs` (starting with GHC 8.8.1) will happily run this invalid program:
```
$ runghc Main.hs
The impossible happened
```
This inconsistent behaviour has lead to less informed people assuming such a program might be actually "valid" Haskell.8.8.2Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/16979`generic-lens` fails Core Lint2020-02-25T01:12:50ZRyan Scott`generic-lens` fails Core Lint[`generic-lens-1.2.0.0`](http://hackage.haskell.org/package/generic-lens-1.2.0.0)'s test suite `generic-lens-syb-tree` fails Core Lint. Here is as small of an example as I can get which demonstrates the issue on every version of GHC from...[`generic-lens-1.2.0.0`](http://hackage.haskell.org/package/generic-lens-1.2.0.0)'s test suite `generic-lens-syb-tree` fails Core Lint. Here is as small of an example as I can get which demonstrates the issue on every version of GHC from 8.2 to HEAD:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE InstanceSigs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE UndecidableInstances #-}
module Bug (strs) where
import Control.Applicative
import Data.Coerce
import Data.Kind
import Data.Monoid
import GHC.Generics
import GHC.TypeLits
main :: IO ()
main = pure ()
data Poly a b
= PNil
| PCons a (Poly b a)
deriving (Show, Generic)
poly :: Poly Int String
poly = PCons 10 (PCons "hello" (PCons 20 (PCons "world" PNil)))
strs :: [String]
strs = toListOf (param @0) poly
toListOf :: Getting (Endo [a]) s a -> s -> [a]
toListOf l = foldrOf l (:) []
{-# INLINE toListOf #-}
foldrOf :: Getting (Endo r) s a -> (a -> r -> r) -> r -> s -> r
foldrOf l f z = flip appEndo z . foldMapOf l (Endo #. f)
{-# INLINE foldrOf #-}
foldMapOf :: Getting r s a -> (a -> r) -> s -> r
foldMapOf l f = getConst #. l (Const #. f)
{-# INLINE foldMapOf #-}
type Getting r s a = (a -> Const r a) -> s -> Const r s
class Profunctor p where
dimap :: (a -> b) -> (c -> d) -> p b c -> p a d
(#.) :: forall a b c q. Coercible c b => q b c -> p a b -> p a c
instance Profunctor (->) where
dimap ab cd bc = cd . bc . ab
{-# INLINE dimap #-}
(#.) _ = coerce (\x -> x :: b) :: forall a b. Coercible b a => a -> b
{-# INLINE (#.) #-}
class HasParam (p :: Nat) s t a b | p t a -> s, p s b -> t, p s -> a, p t -> b where
param :: Applicative g => (a -> g b) -> s -> g t
instance
( GenericN s
, GenericN t
, s ~ Infer t (P n b 'PTag) a
, t ~ Infer s (P n a 'PTag) b
, a ~ ArgAt s n
, b ~ ArgAt t n
, GHasParam n (RepN s) (RepN t) a b
) => HasParam n s t a b where
param = confusing (\f s -> toN <$> gparam @n f (fromN s))
{-# INLINE param #-}
confusing :: Applicative f => Traversal s t a b -> (a -> f b) -> s -> f t
confusing t = \f -> lowerYoneda . lowerCurried . t (liftCurriedYoneda . f)
{-# INLINE confusing #-}
newtype Yoneda f a = Yoneda { runYoneda :: forall b. (a -> b) -> f b }
instance Functor (Yoneda f) where
fmap f m = Yoneda (\k -> runYoneda m (k . f))
instance Applicative f => Applicative (Yoneda f) where
pure a = Yoneda (\f -> pure (f a))
Yoneda m <*> Yoneda n = Yoneda (\f -> m (f .) <*> n id)
newtype Curried f a =
Curried { runCurried :: forall r. f (a -> r) -> f r }
instance Functor f => Functor (Curried f) where
fmap f (Curried g) = Curried (g . fmap (.f))
{-# INLINE fmap #-}
instance (Functor f) => Applicative (Curried f) where
pure a = Curried (fmap ($ a))
{-# INLINE pure #-}
Curried mf <*> Curried ma = Curried (ma . mf . fmap (.))
{-# INLINE (<*>) #-}
lowerYoneda :: Yoneda f a -> f a
lowerYoneda (Yoneda f) = f id
lowerCurried :: Applicative f => Curried f a -> f a
lowerCurried (Curried f) = f (pure id)
liftCurriedYoneda :: Applicative f => f a -> Curried (Yoneda f) a
liftCurriedYoneda fa = Curried (`yap` fa)
{-# INLINE liftCurriedYoneda #-}
yap :: Applicative f => Yoneda f (a -> b) -> f a -> Yoneda f b
yap (Yoneda k) fa = Yoneda (\ab_r -> k (ab_r .) <*> fa)
{-# INLINE yap #-}
type Traversal s t a b
= forall f. Applicative f => (a -> f b) -> s -> f t
class GHasParam (p :: Nat) s t a b where
gparam :: forall g (x :: Type). Applicative g => (a -> g b) -> s x -> g (t x)
instance (GHasParam p l l' a b, GHasParam p r r' a b) => GHasParam p (l :*: r) (l' :*: r') a b where
gparam f (l :*: r) = (:*:) <$> gparam @p f l <*> gparam @p f r
instance (GHasParam p l l' a b, GHasParam p r r' a b) => GHasParam p (l :+: r) (l' :+: r') a b where
gparam f (L1 l) = L1 <$> gparam @p f l
gparam f (R1 r) = R1 <$> gparam @p f r
instance GHasParam p U1 U1 a b where
gparam _ _ = pure U1
instance GHasParam p s t a b => GHasParam p (M1 m meta s) (M1 m meta t) a b where
gparam f (M1 x) = M1 <$> gparam @p f x
instance GHasParam p (Rec (param p) a) (Rec (param p) b) a b where
gparam = recIso
instance {-# OVERLAPPABLE #-}
( GHasParamRec (LookupParam si p) s t a b
) => GHasParam p (Rec si s) (Rec ti t) a b where
gparam f (Rec (K1 x)) = Rec . K1 <$> gparamRec @(LookupParam si p) f x
class GHasParamRec (param :: Maybe Nat) s t a b | param t a b -> s, param s a b -> t where
gparamRec :: forall g. Applicative g => (a -> g b) -> s -> g t
instance GHasParamRec 'Nothing a a c d where
gparamRec _ = pure
instance (HasParam n s t a b) => GHasParamRec ('Just n) s t a b where
gparamRec = param @n
recIso :: Iso (Rec r a p) (Rec r b p) a b
recIso = iso (unK1 . unRec) (Rec . K1)
type Iso s t a b
= forall p f. (Profunctor p, Functor f) => p a (f b) -> p s (f t)
iso :: (s -> a) -> (b -> t) -> Iso s t a b
iso sa bt = dimap sa (fmap bt)
{-# INLINE iso #-}
type family LookupParam (a :: k) (p :: Nat) :: Maybe Nat where
LookupParam (param (n :: Nat)) m = 'Nothing
LookupParam (a (_ (m :: Nat))) n = IfEq m n ('Just 0) (MaybeAdd (LookupParam a n) 1)
LookupParam (a _) n = MaybeAdd (LookupParam a n) 1
LookupParam a _ = 'Nothing
type family MaybeAdd (a :: Maybe Nat) (b :: Nat) :: Maybe Nat where
MaybeAdd 'Nothing _ = 'Nothing
MaybeAdd ('Just a) b = 'Just (a + b)
type family IfEq (a :: k) (b :: k) (t :: l) (f :: l) :: l where
IfEq a a t _ = t
IfEq _ _ _ f = f
data Sub where
Sub :: Nat -> k -> Sub
type family ReplaceArg (t :: k) (pos :: Nat) (to :: j) :: k where
ReplaceArg (t a) 0 to = t to
ReplaceArg (t a) pos to = ReplaceArg t (pos - 1) to a
ReplaceArg t _ _ = t
type family ReplaceArgs (t :: k) (subs :: [Sub]) :: k where
ReplaceArgs t '[] = t
ReplaceArgs t ('Sub n arg ': ss) = ReplaceArgs (ReplaceArg t n arg) ss
type family ArgAt (t :: k) (n :: Nat) :: j where
ArgAt (t a) 0 = a
ArgAt (t a) n = ArgAt t (n - 1)
type family Unify (a :: k) (b :: k) :: [Sub] where
Unify (p n _ 'PTag) a' = '[ 'Sub n a']
Unify (a x) (b y) = Unify x y ++ Unify a b
Unify a a = '[]
type family (xs :: [k]) ++ (ys :: [k]) :: [k] where
'[] ++ ys = ys
(x ': xs) ++ ys = x ': (xs ++ ys)
type family Infer (s :: *) (a' :: *) (b :: *) :: * where
Infer (s a) a' b
= ReplaceArgs (s a) (Unify a' b)
Infer s _ _ = s
data PTag = PTag
type family P :: Nat -> k -> PTag -> k
type family Param :: Nat -> k where
type family Indexed (t :: k) (i :: Nat) :: k where
Indexed (t a) i = Indexed t (i + 1) (Param i)
Indexed t _ = t
newtype Rec (p :: Type) a x = Rec { unRec :: K1 R a x }
type family Zip (a :: Type -> Type) (b :: Type -> Type) :: Type -> Type where
Zip (M1 mt m s) (M1 mt m t)
= M1 mt m (Zip s t)
Zip (l :+: r) (l' :+: r')
= Zip l l' :+: Zip r r'
Zip (l :*: r) (l' :*: r')
= Zip l l' :*: Zip r r'
Zip (Rec0 p) (Rec0 a)
= Rec p a
Zip U1 U1
= U1
class
( Coercible (Rep a) (RepN a)
, Generic a
) => GenericN (a :: Type) where
type family RepN (a :: Type) :: Type -> Type
type instance RepN a = Zip (Rep (Indexed a 0)) (Rep a)
toN :: RepN a x -> a
fromN :: a -> RepN a x
instance
( Coercible (Rep a) (RepN a)
, Generic a
) => GenericN a where
toN :: forall x. RepN a x -> a
toN = coerce (to :: Rep a x -> a)
{-# INLINE toN #-}
fromN :: forall x. a -> RepN a x
fromN = coerce (from :: a -> Rep a x)
{-# INLINE fromN #-}
```8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17057Partially applied type family causes GHC internal error since GHC 8.82020-02-25T01:11:30Zsheafsam.derbyshire@gmail.comPartially applied type family causes GHC internal error since GHC 8.8On GHC 8.8.0.20190721, the following program
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies ...On GHC 8.8.0.20190721, the following program
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Kind
( Type )
import Data.Proxy
( Proxy(Proxy) )
data HList :: [Type] -> Type where
type family Foo (xs :: [Type]) (ys :: [Type]) :: [Type] where
foo :: forall (is :: [Type]). HList is -> HList (Foo is)
foo = case Proxy @is of
_ -> undefined
```
causes a GHC internal error:
```
bug.hs:21:50: error:
* Expecting one more argument to `Foo is'
Expected kind `[*]', but `Foo is' has kind `[*] -> [*]'
* In the first argument of `HList', namely `(Foo is)'
In the type signature:
foo :: forall (is :: [Type]). HList is -> HList (Foo is)
|
21 | foo :: forall (is :: [Type]). HList is -> HList (Foo is)
|
bug.hs:22:19: error:
* GHC internal error: `is' is not in scope during type checking, but it passed the renamer
tcl_env of environment: []
* In the type `is'
In the expression: Proxy @is
In the expression: case Proxy @is of { _ -> undefined }
|
22 | foo = case Proxy @is of
| ^^
```
On GHC 8.6.5, the internal error does not occur and as expected we simply get an error for a partially applied type family.
```
bug.hs:21:50: error:
* Expecting one more argument to `Foo is'
Expected kind `[*]', but `Foo is' has kind `[*] -> [*]'
* In the first argument of `HList', namely `(Foo is)'
In the type signature:
foo :: forall (is :: [Type]). HList is -> HList (Foo is)
|
21 | foo :: forall (is :: [Type]). HList is -> HList (Foo is)
|
```
This came up after I had modified a type family by adding an extra argument, and had forgotten to pass in that extra argument somewhere.8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17296TH-reified data family instances lack arguments since 8.82020-02-25T01:10:18ZChuckTH-reified data family instances lack arguments since 8.8## Summary
Before GHC 8.8, data family instances' arguments were available from `reify`. In GHC 8.8, they are not.
## Steps to reproduce
Create two files:
ReportErr1.hs
```
module ReportErr1 where
import Language.Haskell.TH.Syntax
...## Summary
Before GHC 8.8, data family instances' arguments were available from `reify`. In GHC 8.8, they are not.
## Steps to reproduce
Create two files:
ReportErr1.hs
```
module ReportErr1 where
import Language.Haskell.TH.Syntax
reportOnDataFamily :: Name -> Q a
reportOnDataFamily familyName = do
fam <- reify familyName
case fam of
FamilyI _ xs -> fail $ "Here is my report: " <> show xs
_ -> fail ":("
```
ReportErr2.hs
```{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
import ReportErr1
data family Foo :: * -> *
data instance Foo Bool
$(reportOnDataFamily ''Foo)
```
Build:
```
$ ghc -dynamic ReportErr1
$ ghc ReportErr2
```
## Expected behavior
The instance's argument `Bool` should be available. It was before 8.8:
```
8.4.4 Here is my report: [DataInstD [] Main.Foo [ConT GHC.Types.Bool] Nothing [] []]
8.6.4 Here is my report: [DataInstD [] Main.Foo [ConT GHC.Types.Bool] Nothing [] []]
8.6.5 Here is my report: [DataInstD [] Main.Foo [ConT GHC.Types.Bool] Nothing [] []]
8.8.1 Here is my report: [DataInstD [] Nothing (ConT Main.Foo) Nothing [] []]
8.9.20190601 Here is my report: [DataInstD [] Nothing (ConT Main.Foo) Nothing [] []]
```
In describing this change, the [8.8 release notes](https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8#template-haskell-21500) say that the data family instances' arguments should be available in the Type field. The Type field is to contain _"the data family name applied to its arguments"_, but here it contains only the data family name.
## Environment
* GHC version used: 8.8.1
Optional:
* Operating System: NixOS
* System Architecture: x86_648.8.2Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/17334GHC can't find weight for edge that should have one2020-02-25T01:09:40ZBodigrimGHC can't find weight for edge that should have one## Summary
GHC panics while compiling `fetchAndIntArray#` / `fetchOrIntArray#`.
```
[ 5 of 13] Compiling Data.Bit.MutableTS
ghc: panic! (the 'impossible' happened)
(GHC version 8.8.1 for x86_64-apple-darwin):
Can't find weight for...## Summary
GHC panics while compiling `fetchAndIntArray#` / `fetchOrIntArray#`.
```
[ 5 of 13] Compiling Data.Bit.MutableTS
ghc: panic! (the 'impossible' happened)
(GHC version 8.8.1 for x86_64-apple-darwin):
Can't find weight for edge that should have one
triple (nQaY, nQwj, sKLs)
updates [(cPjA, nQwR, sL5U), (cPjx, nQwQ, sL5U),
...
(cOPS, nQwl, sKKV), (cOPy, nQwk, sKLs), (nQaY, nQwj, sKLs),
...
(cOEj, nQv2, sKED), (cOEm, nQv1, sKED)]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable
pprPanic, called at compiler/nativeGen/CFG.hs:423:11 in ghc:CFG
```
## Steps to reproduce
```
git clone https://github.com/Bodigrim/bitvec.git
git checkout bc84af009921802106239d5e963e00abd1ec7003
stack build
```
This will fail with an error message, quoted above.
Sorry for such a broad description; at the moment I do not have time to whittle it down. I suspect that the problematic piece is in `Data.Bit.InternalTS`:
```
let W# andMask# = hiMask lenMod
W# orMask# = x .&. loMask lenMod
primitive $ \state ->
let !(# state', _ #) = fetchAndIntArray# mba loIx# (word2Int# andMask#) state in
let !(# state'', _ #) = fetchOrIntArray# mba loIx# (word2Int# orMask#) state' in
(# state'', () #)
```
## Expected behavior
I expect this package to compile successfully.
## Environment
* GHC version used: 8.8.1 for x86_64-apple-darwin
It seems to be a regression since GHC 8.6.5, as witnessed by these Travis builds:
* GHC 8.6.5: https://travis-ci.org/Bodigrim/bitvec/jobs/595834070
* GHC 8.8.1: https://travis-ci.org/Bodigrim/bitvec/jobs/5958340698.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17355Buggy validity checks for built-in classes2020-02-25T01:05:57ZAdam GundryBuggy validity checks for built-in classesBuilt-in classes such as `Generic` and `HasField` do not appear to have validity checks applied properly. In particular, it is possible to give impredicative instances without using `ImpredicativeTypes`.
The following obvious nonsense i...Built-in classes such as `Generic` and `HasField` do not appear to have validity checks applied properly. In particular, it is possible to give impredicative instances without using `ImpredicativeTypes`.
The following obvious nonsense is accepted (with warnings) by GHC 8.8.1. In GHC 8.6.5 and earlier it asks for `FlexibleInstances`, but then fails with `Illegal polymorphic type: forall a. a`, which is a reasonable (if terse) response. Ideally it should fail with such an error without even requesting `FlexibleInstances`.
```hs
{-# LANGUAGE ExplicitForAll #-}
module M1 where
import GHC.Generics
instance Generic (forall a . a)
```
Here's another example that should not be accepted:
```hs
{-# LANGUAGE RankNTypes, DataKinds #-}
module M2 where
import GHC.Records
data Foo = Foo { poly :: forall a. a -> a }
instance HasField "myPoly" Foo (forall a. a -> a) where
getField (Foo x) = x
```
From a brief look, I suspect this may be related to fd0f0334189c0c5c9b186bd1b009f706d3d86086, which refactored `checkValidInstHead` and AFAICS dropped the relevant checks.
(Thanks to @phadej for spotting this in https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-541518676, although it is broader than just `HasField`.)8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17384:info incorrectly parenthesizes GADT return types in 8.8.12020-02-25T01:05:27ZRyan Scott:info incorrectly parenthesizes GADT return types in 8.8.1Load this code into GHCi 8.8.1:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
module Bug where
import Data.Kind
data T :: Type -> Type where
MkT :: T (Maybe Bool)
```
And then run `:info T`. You'll get some unusual r...Load this code into GHCi 8.8.1:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
module Bug where
import Data.Kind
data T :: Type -> Type where
MkT :: T (Maybe Bool)
```
And then run `:info T`. You'll get some unusual results:
```
$ /opt/ghc/8.8.1/bin/ghci Bug.hs
GHCi, version 8.8.1: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :info T
type role T nominal
data T a where
MkT :: T Maybe Bool
-- Defined at Bug.hs:7:1
```
Notice how the return type is `T Maybe Bool`, which is wrong. Compare this to GHCi 8.6.5:
```
$ /opt/ghc/8.6.5/bin/ghci Bug.hs
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :info T
type role T nominal
data T a where
MkT :: T (Maybe Bool)
-- Defined at Bug.hs:7:1
```
This was a regression introduced by someone who shall remain unnamed in 9d9e35574a92773d872efd58a67339a9e054a9f1. Coincidentally, someone who shall remain unnamed will be preparing a fix shortly.8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17353ghc 8.8.1 fails on macOS 10.15 Catalina2020-02-24T22:03:07Zfxcoudertghc 8.8.1 fails on macOS 10.15 Catalina## Summary
ghc 8.8.1 compiled on macOS 10.15 with system compiler (Xcode 11.1) completes bootstrap, but the compiler later fails to run simple programs with a memory-related error:
```
ghc: mmap 131072 bytes at 0x0: Operation not permi...## Summary
ghc 8.8.1 compiled on macOS 10.15 with system compiler (Xcode 11.1) completes bootstrap, but the compiler later fails to run simple programs with a memory-related error:
```
ghc: mmap 131072 bytes at 0x0: Operation not permitted
ghc: Try specifying an address with +RTS -xm<addr> -RTS
ghc: internal error: m32_allocator_init: Failed to map
(GHC version 8.8.1 for x86_64_apple_darwin)
```
This is reproducible in several setups, both inside VMs and on physical hardware.
## Steps to reproduce
On macOS 10.15 Catalina, with Xcode 11.1 (system compiler):
- ghc 8.8.1 is built from ghc-8.8.1-src.tar.xz (as part of Homebrew)
- bootstrap completes
- Run a simple test, watch if fail:
```
rmeur /tmp $ cat hello.rs
main = putStrLn "Hello Homebrew"
rmeur /tmp $ /usr/local/Cellar/ghc/8.8.1/bin/runghc -v hello.rs
Glasgow Haskell Compiler, Version 8.8.1, stage 2 booted by GHC version 8.6.5
Using binary package database: /usr/local/Cellar/ghc/8.8.1/lib/ghc-8.8.1/package.conf.d/package.cache
package flags []
loading package database /usr/local/Cellar/ghc/8.8.1/lib/ghc-8.8.1/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.3
wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0
wired-in package base mapped to base-4.13.0.0
wired-in package rts mapped to rts
wired-in package template-haskell mapped to template-haskell-2.15.0.0
wired-in package ghc mapped to ghc-8.8.1
package flags []
loading package database /usr/local/Cellar/ghc/8.8.1/lib/ghc-8.8.1/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.3
wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0
wired-in package base mapped to base-4.13.0.0
wired-in package rts mapped to rts-1.0
wired-in package template-haskell mapped to template-haskell-2.15.0.0
wired-in package ghc mapped to ghc-8.8.1
*** Desugar:
*** Simplify [expr]:
!!! Simplify [expr]: finished in 0.18 milliseconds, allocated 0.056 megabytes
*** CorePrep [expr]:
!!! CorePrep [expr]: finished in 3.17 milliseconds, allocated 1.705 megabytes
*** ByteCodeGen [Ghci1]:
!!! ByteCodeGen [Ghci1]: finished in 0.10 milliseconds, allocated 0.029 megabytes
ghc: mmap 131072 bytes at 0x0: Operation not permitted
ghc: Try specifying an address with +RTS -xm<addr> -RTS
ghc: internal error: m32_allocator_init: Failed to map
(GHC version 8.8.1 for x86_64_apple_darwin)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Expected behavior
The program should run without error.
## Environment
* GHC version used:
Optional:
* Operating System: macOS 10.15 Catalina
* System Architecture: x86_648.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/16877GHCi panics using -fdefer-type-errors when pattern matching on types with mul...2020-02-18T12:30:12ZBerengalGHCi panics using -fdefer-type-errors when pattern matching on types with multiple constructors using out-of-scope variables# Summary
With -fdefer-type-errors enabled GHCi will panic on certain errors involving pattern matching on types with multiple constructors. At least as far as I can tell.
# Steps to reproduce
The following is the smallest module I co...# Summary
With -fdefer-type-errors enabled GHCi will panic on certain errors involving pattern matching on types with multiple constructors. At least as far as I can tell.
# Steps to reproduce
The following is the smallest module I could find that causes the panic:
```
foo = x
where (x:xs) = bar
```
GHCi command and output:
```
▶ ghci -ignore-dot-ghci -fdefer-type-errors Foo.hs
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( Foo.hs, interpreted )
Foo.hs:2:18: warning: [-Wdeferred-out-of-scope-variables]
Variable not in scope: bar :: [a1]
|
2 | where (x:xs) = bar
| ^^^
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-linux):
getIdFromTrivialExpr
\ (@ a_a1x4) -> case ds_s1yU @ a_a1x4 of wild_Xb { }
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreUtils.hs:977:18 in ghc:CoreUtils
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
The equivalent using `let` also panics. The pattern match in the where is neccessary, as is using a matched variable in the main expression (either one will do). Matching on a tuple does not cause a panic, nor does matching on `data Foo a = Foo a a`, but matching on `data Foo a = Foo a a | Bar a a` panics regardless of which constructor is chosen.
# Expected behavior
GHCi doesn't panic, but either loads the module correctly or explains why it can't do so.
# Environment
* GHC version used: 8.6.5
Optional:
* Operating System: Arch-linux
* System Architecture: x86_648.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17629internal error when I pass -hT to a profiling build2020-02-06T22:20:14ZVanessa McHaleinternal error when I pass -hT to a profiling build## Summary
I get
```
decompress/compress
lzlib-test: internal error: dumpCensus; doHeapProfile
(GHC version 8.8.1 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Aborted (core ...## Summary
I get
```
decompress/compress
lzlib-test: internal error: dumpCensus; doHeapProfile
(GHC version 8.8.1 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
when trying to run a test suite with `+RTS -hT`
## Steps to reproduce
Build [lzlib](https://github.com/vmchale/lzlib) with
```
cabal test --enable-profiling
```
and download test data with
```
make
```
Then run the generated executable with:
```
dist-newstyle/build/x86_64-linux/ghc-8.8.1/lzlib-0.3.0.5/t/lzlib-test/build/lzlib-test/lzlib-test +RTS -hT
```
## Expected behavior
It should [generate a heap profile](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/runtime_control.html#rts-options-for-profiling) and not fail with such an error.
It works fine if I pass `-h` instead of `-hT`.
## Environment
* GHC version used: 8.8.1, 8.8.2 release candidate
I can't reproduce this with 8.6.5 or earlier. It seems to be fixed in 8.10.1
Optional:
* Operating System: Linux
* System Architecture: x86_64, aarch648.8.2