GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-03-02T16:58:07Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14533Make GHC more robust against PC crashes by using atomic writes2021-03-02T16:58:07ZNiklas Hambüchenmail@nh2.meMake GHC more robust against PC crashes by using atomic writesYesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).
That made me think if we should change ghc to write its output with atomic moves.
Discussion on `#gh...Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).
That made me think if we should change ghc to write its output with atomic moves.
Discussion on `#ghc`:
```
bgamari:
nh2: well, perhaps
I'm not sure it's terribly common for compilers to take such precautions though
and if we were to do it for interface files then presumably we would also want to do it for object files
siarheit_:
that would be very nice
geekosaur:
compilers in general are happy to write out incomplete/garbage object files
bgamari:
it seems that way
nh2:
bgamari: right, if we wanted to do it we should do it for all files ghc writes.
Possible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about
Phyx-:
most compilers also don't do the aggressive recompilation avoidance things we do either..
corrupt hi files wouldn't be an issue if the next time it would override them :)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make GHC more robust against PC crashes by using atomic writes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Bug","description":"Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).\r\n\r\nThat made me think if we should change ghc to write its output with atomic moves.\r\n\r\nDiscussion on `#ghc`:\r\n\r\n{{{\r\nbgamari:\r\nnh2: well, perhaps\r\nI'm not sure it's terribly common for compilers to take such precautions though\r\nand if we were to do it for interface files then presumably we would also want to do it for object files\r\n\r\nsiarheit_:\r\nthat would be very nice\r\n\r\ngeekosaur:\r\ncompilers in general are happy to write out incomplete/garbage object files\r\n\r\nbgamari:\r\nit seems that way\r\n\r\nnh2:\r\nbgamari: right, if we wanted to do it we should do it for all files ghc writes.\r\nPossible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about\r\n\r\nPhyx-:\r\nmost compilers also don't do the aggressive recompilation avoidance things we do either..\r\ncorrupt hi files wouldn't be an issue if the next time it would override them :)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/18940ghc: internal error: allocation of 2099240 bytes too large2021-01-24T09:07:24ZAndrea Bedinighc: internal error: allocation of 2099240 bytes too large## Summary
GHCi crashes when issued `:show-bindings`.
## Steps to reproduce
The following produces a crash
```
$ cabal repl -w ghc-8.10
Build profile: -w ghc-8.10.2 -O1
In order, the following will be built (use -v for more details):...## Summary
GHCi crashes when issued `:show-bindings`.
## Steps to reproduce
The following produces a crash
```
$ cabal repl -w ghc-8.10
Build profile: -w ghc-8.10.2 -O1
In order, the following will be built (use -v for more details):
- haskell-odbc-0.1.0.0 (lib:lane-stuff) (first run)
Preprocessing library 'lane-stuff' for haskell-odbc-0.1.0.0..
GHCi, version 8.10.2: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/andrea/.ghci
[1 of 3] Compiling Lanes.Types ( Lanes/Types.hs, interpreted )
[2 of 3] Compiling Lanes.IO ( Lanes/IO.hs, interpreted )
[3 of 3] Compiling Lanes ( Lanes.hs, interpreted )
Ok, three modules loaded.
λ> lpps <- readFile
λ> :show bindings
lpps :: Data.Vector.Vector MyData = _
λ> length lpps
137473
λ> :show bindings
ghc: internal error: allocation of 2099240 bytes too large (GHC should have complained at compile-time)
(GHC version 8.10.2 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
cabal: repl failed for lib:lane-stuff from haskell-odbc-0.1.0.0. The build
process terminated with exit code -6
```
Note that only the second call to `:show bindings` fails. The `readFile` function simply reads a csv file with Cassava.
```
readFile :: IO (Vector MyData)
readFile = do
bs <- LBS.readFile "mydatafile.csv"
let Right (_, v) = decodeByName bs
pure v
```
The file `mydatafile.csv` is 7MB in size. Unfortunately I cannot share it.
## Expected behavior
I expect GHCi not to crash.
## Environment
* GHC version used: 8.10.2 (ghcup)
Optional:
* Operating System: Ubuntu
* System Architecture: x86
https://mpickering.github.io/ide/posts/2020-08-04-measuring-memory-size.html seems relevant, it points to #12492 but that seems to be related to `ghc-heap-view` or `ghc-datasize` which should not be at play here.https://gitlab.haskell.org/ghc/ghc/-/issues/19125GHC bug! Heap Overflow error during Cabal Install - Panic! (the 'impossible' ...2020-12-28T14:02:45Zrobert watsonGHC bug! Heap Overflow error during Cabal Install - Panic! (the 'impossible' happened)using: cabal install --ghc-options="+RTS -M2G" -j1 --force-reinstalls Agda
Trying to install Agda 2.6.1.2 for about the fifth time.
The following was returned:
.
.
.
[297 of 369] Compiling Agda. Typechecking.Rules.LHS.Unify ( src/full/...using: cabal install --ghc-options="+RTS -M2G" -j1 --force-reinstalls Agda
Trying to install Agda 2.6.1.2 for about the fifth time.
The following was returned:
.
.
.
[297 of 369] Compiling Agda. Typechecking.Rules.LHS.Unify ( src/full/Agda/TypeChecker: panic! (the 'impossible' happened)
(GHC version 8.8.4 for x86_64-unknown-linux):
heap overflow
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
cabal: Failed to build Agda-2.6.1.2
(Am using Ubuntu 20.04.01 LTS, I was trying to control the heap overflow problem with -M2G as I only have 4GB memory - I'm quite happy to leave it running for a few hours, but it should still work eventually!!)https://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/18984Pandoc-2.11.2 build failed on FreeBSD-11.4 i386 system2020-12-04T21:16:18ZwenhepingPandoc-2.11.2 build failed on FreeBSD-11.4 i386 system
Pandoc-2.11.2 build failed on FreeBSD-11.4 i386 system, while success on amd64 system. The last lines of buildlog is:
```
\[118 of 184\] Compiling Text.Pandoc.Writers.ConTeXt
\[119 of 184\] Compiling Text.Pandoc.PDF
\[120 of 184\] Comp...
Pandoc-2.11.2 build failed on FreeBSD-11.4 i386 system, while success on amd64 system. The last lines of buildlog is:
```
\[118 of 184\] Compiling Text.Pandoc.Writers.ConTeXt
\[119 of 184\] Compiling Text.Pandoc.PDF
\[120 of 184\] Compiling Text.Pandoc.Lua.Module.Utils
\[121 of 184\] Compiling Text.Pandoc.Writers.OpenDocument
\[122 of 184\] Compiling Text.Pandoc.Writers.ODT
\[123 of 184\] Compiling Text.Pandoc.Writers.MediaWiki
\[124 of 184\] Compiling Text.Pandoc.Writers.XWiki
\[125 of 184\] Compiling Text.Pandoc.Writers.JATS.Table
\[126 of 184\] Compiling Text.Pandoc.Writers.JATS
\[127 of 184\] Compiling Text.Pandoc.Writers.ICML
\[128 of 184\] Compiling Text.Pandoc.Writers.HTML
ghc: panic! (the 'impossible' happened) (GHC version 8.10.2: ghc: panic! (the 'impossible' happened) (GHC version 8.10.2: ghc: panic! (the 'impossible' happened) (GHC version 8.10.2: exprToType
Call stack: CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1179:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreSyn.hs:2087:28 in ghc:CoreSyn
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/18946Intermittent failure when building with GHC 8.10.2 on Windows2020-11-26T23:07:22ZJohn KyIntermittent failure when building with GHC 8.10.2 on WindowsIn our Windows builds on Github Actions, sometimes the compiler fails like this:
```
In file included from C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\lib/include/HsFFI.h:20,
from cbits\closure_size.c:27:...In our Windows builds on Github Actions, sometimes the compiler fails like this:
```
In file included from C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\lib/include/HsFFI.h:20,
from cbits\closure_size.c:27:0: error:
C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\lib/include/stg/Types.h:26:9: warning: #warning "Mismatch between __USE_MINGW_ANSI_STDIO definitions. If using Rts.h make sure it is the first header included." [-Wcpp]
26 | # warning "Mismatch between __USE_MINGW_ANSI_STDIO definitions. \
| ^~~~~~~
```
The failure is very intermittent and it isn't clear if the fault is with Github Actions or with GHC, but it has happened at least twice.
For example:
* https://github.com/input-output-hk/cardano-node/runs/1393454458?check_suite_focus=true
* https://github.com/input-output-hk/cardano-node/runs/1379893830?check_suite_focus=true
There was also this:
```
Access violation in generated code when reading 0xbd68
Attempting to reconstruct a stack trace...
Frame Code address
* 0x48ffb50 0x39513e4 C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\bin\ghc.exe+0x35513e4
* 0x48ffbf0 0x396cd17 C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\bin\ghc.exe+0x356cd17
* 0x48ffc40 0x396dcb4 C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\bin\ghc.exe+0x356dcb4
* 0x48ffd00 0x393b7bb C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\bin\ghc.exe+0x353b7bb
* 0x48ffe20 0x39a8623 C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\bin\ghc.exe+0x35a8623
* 0x48ffef0 0x40138c C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\bin\ghc.exe+0x138c
* 0x48fff20 0x4014bb C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\bin\ghc.exe+0x14bb
* 0x48fff50 0x7ffbd2307974 C:\windows\System32\KERNEL32.DLL+0x17974
* 0x48fffd0 0x7ffbd3b8a271 C:\windows\SYSTEM32\ntdll.dll+0x6a271
```
See here:
* https://github.com/input-output-hk/cardano-node/pull/2086/checks?check_run_id=1393807980https://gitlab.haskell.org/ghc/ghc/-/issues/18951Ghci does not terminate cleanly after Stack Overflow Error2020-11-18T20:59:51ZHannes SiebenhandlGhci does not terminate cleanly after Stack Overflow Error## Summary
In certain cases, after a Stack Overflow occurs, Ghci threads are not correctly cleaned up, letting them linger with 100% CPU usage.
## Steps to reproduce
Content of `Err.hs`:
```haskell
data X a = X
instance Show a => Sho...## Summary
In certain cases, after a Stack Overflow occurs, Ghci threads are not correctly cleaned up, letting them linger with 100% CPU usage.
## Steps to reproduce
Content of `Err.hs`:
```haskell
data X a = X
instance Show a => Show (X a) where
x = show (X :: X Int)
```
Invoke:
```bash
> ghci Err.hs +RTS -M2G -K100M -RTS -e "x"
Err.hs:2:10-29: warning: [-Wmissing-methods]
• No explicit implementation for
either ‘showsPrec’ or ‘show’
• In the instance declaration for ‘Show (X a)’
|
2 | instance Show a => Show (X a) where
| ^^^^^^^^^^^^^^^^^^^^
<interactive>: stack overflow
```
However, this computation does not terminate and you can verify in `top` or `htop` that there is at least one `ghc` thread with 100% CPU usage.
Note, that you can get the desired behaviour, *if* you omit the typeclass constraint on `a` in the Instance declaration. (Assume file `Ok.hs`)
```haskell
data X a = X
instance Show (X a) where
x = show (X :: X Int)
```
Now the invocation `ghci Ok.hs +RTS -M2G -K100M -RTS -e "x"` terminates with a `Stack Overflow` correctly.
Moreover, reducing the amount of stack (e.g. to `-K1M`) also solves the issue.
## Expected behavior
Eventually terminate with a `stack overflow`.
What do you expect the reproducer described above to do?
It will not terminate and also not react on ctrl+c or other signals. You have to send sigkill to it.
## Environment
* GHC version used: 8.8.4
Optional:
* Operating System: NixOS
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/13547Lint error in arrows program2020-11-14T10:00:44Zcipher1024Lint error in arrows programWhen building with `stack build --resolver lts-7.20`and `stack build --resolver lts-8.8`, i.e. with ghc-8.0.1 and ghc-8.0.2.
```
[37 of 60] Compiling Document.Phase.Proofs ( src/Document/Phase/Proofs.hs, .stack-work/dist/x86_64-osx/...When building with `stack build --resolver lts-7.20`and `stack build --resolver lts-8.8`, i.e. with ghc-8.0.1 and ghc-8.0.2.
```
[37 of 60] Compiling Document.Phase.Proofs ( src/Document/Phase/Proofs.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.0.0/build/Document/Phase/Proofs.o )
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-apple-darwin):
StgCmmEnv: variable not found
$dTypeable_aZSM
local binds for:
$sunionWith_$sunionWithKey
$sfromList1
$sfromList3
$sfromList
$s$fOrdEither
$s$fMonadReaderrReaderT
$s$fIsTupleconstrIdentity
$s$fIsTupleconstr(,,,,)
$s$fIsTupleconstr(,,,)
$s$fIsTupleconstr(,,)
$s$fIsTupleconstr(,,)2
$s$fIsTupleconstr(,)1
$s$fIsTupleconstr(,)
$s$fIsTupleconstr(,)2
$s$fHasMachineP2p
$fNFDataEventRefA
$fMonoidEventRefA
$fGenericEventRefA
$wmake_phase4
make_phase1
$wpoly_go10
make_phase2
make_phase3
make_phase5
$fNFDataEventRefA4
$fNFDataEventRefA2
$stypeRep#78
$swithCommand8
$stypeRep#54
$swithCommand5
$stypeRep#11
$swithCommand2
$stypeRep#74
$stypeRep#81
$stypeRep#15
$stypeRep#20
$stypeRep#79
$stypeRep#80
$stypeRep#70
$stypeRep#75
$stypeRep#58
$stypeRep#66
$stypeRep#71
$stypeRep#62
$stypeRep#8
$stypeRep#67
$stypeRep#63
$stypeRep#59
$stypeRep#50
$stypeRep#55
$stypeRep#38
$stypeRep#46
$stypeRep#51
$stypeRep#42
$stypeRep#47
$stypeRep#43
$stypeRep#34
$stypeRep#39
$stypeRep#31
$stypeRep#35
$stypeRep#28
$stypeRep#24
$stypeRep#25
$stypeRep#21
$stypeRep#3
$stypeRep#16
$stypeRep#7
$stypeRep#12
$stypeRep#2
$smakeCell8
$smakeCell7
$smakeCell40
$smakeCell39
$smakeCell36
$smakeCell35
$smakeCell32
$smakeCell31
$smakeCell4
$smakeCell28
$smakeCell27
$smakeCell24
$smakeCell23
$smakeCell3
$smakeCell20
$smakeCell19
$smakeCell16
$smakeCell15
$smakeCell12
$smakeCell11
$wpoly_go5
$wgo5
$sfromList_go5
$wpoly_go2
$sfromList2
$s$fOrd(,)
$sfromList_fromList'1
$wpoly_go1
$s$fEqEither
$s$fOrdEither_$s$fOrdEither_$cp1Ord
$s$fEq(,)
$s$fOrd(,)_$s$fOrd(,)_$cp1Ord
$s$fMonadRWST
$s$fMonadReaderrReaderT1
$s$fMonadReaderT
$s$fApplicativeReaderT
$s$fMonadReaderT_$s$fMonadReaderT_$cfail
$s$fMonadReaderT_$s$fMonadReaderT_$c>>
$s$fMonadReaderT_$s$fMonadReaderT_$c>>=
$s$fMonadReaderT_$s$fMonadReaderT_$cp1Monad
$s$fMonadRWST_$s$fMonadRWST_$cfail
$s$fMonadRWST_$s$fMonadRWST_$c>>
$s$fMonadRWST_$s$fMonadRWST_$c>>=
$s$fMonadRWST_$s$fMonadRWST_$cp1Monad
$s$fIsTupleconstr(,,,,)_$s$fLatexArg[]
$s$fIsTupleconstr(,,,,)1
$s$fIsTupleconstr(,,,)_$s$fLatexArg[]
$s$fIsTupleconstr(,,,)_irred2
$s$fIsTupleconstr(,,)_$s$fLatexArg[]
$s$fIsTupleconstr(,,)_$dLatexArgFromString
$s$fIsTupleconstr(,,)_$s$fLatexArgFromStringConc
$s$fIsTupleconstr(,,)_irred1
$s$fIsTupleconstr(,,)_$s$fLatexArgNonEmpty
$s$fIsTupleconstr(,,)1
$s$fIsTupleconstr(,)3
$s$fHasMachineP1p
$s$fHasMachineP2p1
$s$fHasMachineP2p2
$s$fHasMachineP2p3
$s$fHasMachineP2p4
$s$fHasMachineP2p5
$s$fHasMachineP2p6
$s$fHasMachineP1p_$s$fHasMachineP1p_$cp5HasMachineP1
$s$fHasMachineP1p_$s$fHasMachineP1p_$cp4HasMachineP1
$s$fHasMachineP1p_$s$fHasMachineP1p_$cp3HasMachineP1
$s$fHasMachineP1p_$s$fHasMachineP1p_$cp2HasMachineP1
$s$fHasMachineP1p_$s$fHasMachineP1p_$cp1HasMachineP1
$s$fEq(,)_$dEq1
$s$fEq(,)_$dEq
$s$fApplicativeReaderT_$s$fFunctorReaderT_$c<$
$s$fApplicativeReaderT_$s$fFunctorReaderT_$cfmap
$s$fApplicativeReaderT_$s$fFunctorReaderT
$s$fApplicativeRWST
$s$fApplicativeReaderT_$dApplicative
$s$fApplicativeReaderT_$s$fApplicativeReaderT_$c<*>
$s$fApplicativeReaderT_$s$fMonadReaderT_$creturn
$s$fApplicativeReaderT_$s$fApplicativeReaderT_$cp1Applicative
$s$fApplicativeRWST_$dFunctor
$s$fApplicativeRWST_$s$fApplicativeRWST_$c<*>
$s$fApplicativeRWST_$s$fApplicativeRWST_$cpure
$s$fApplicativeRWST_$s$fApplicativeRWST_$cp1Applicative
$fNFDataEventRefA1
$fNFDataEventRefA3
$w$dNFData2
$w$dNFData1
$w$dNFData
$fNFDataEventRefA_$crnf
$wgo
$fMonoidEventRefA_$cmconcat
$fMonoidEventRefA_$cmappend
$fMonoidEventRefA_$cmempty
$fGenericEventRefA_$cto
$fGenericEventRefA_$cfrom
make_phase4
ruleProxies_rSKY
refinement_parser_rSL2
$w$smiddle
$w$sgreater
$sfilterGt1
$sfilterLt1
$sinsert_$sgo10
$sinsert_$sgo5
$sleadsTo1
$wpoly_go3
$wpoly_go4
$slookup5
$slookup7
$smakeCell2
$smakeCell6
$smakeCell10
$smakeCell14
$smakeCell18
$smakeCell22
$smakeCell26
$smakeCell30
$smakeCell34
$smakeCell38
$wpoly_go6
$wpoly_go7
$wpoly_go8
$sshowStringP1
$strim1
$strim3
$sunions1
$sunless_eta
$swithCommand1
$swithCommand4
$swithCommand7
lvl_r2714
lvl1_r2715
go_r2716
$wgo1_r2717
lvl2_r2718
lvl3_r2719
lvl4_r271a
lvl5_r271b
lvl6_r271c
lvl7_r271d
lvl8_r271e
lvl9_r271f
lvl10_r271g
lvl11_r271h
lvl12_r271i
lvl13_r271j
lvl14_r271k
lvl15_r271l
lvl16_r271m
lvl17_r271n
lvl18_r271o
lvl19_r271p
lvl20_r271q
lvl21_r271r
lvl22_r271s
lvl23_r271t
lvl24_r271u
lvl25_r271v
lvl26_r271w
lvl27_r271x
lvl28_r271y
lvl29_r271z
lvl30_r271A
lvl31_r271B
lvl32_r271C
lvl33_r271D
lvl34_r271E
lvl35_r271F
lvl36_r271G
lvl37_r271H
lvl38_r271I
lvl39_r271J
lvl40_r271K
lvl49_r2723
lvl50_r2724
lvl51_r2725
lvl52_r2726
lvl53_r2727
lvl54_r2728
lvl55_r2729
lvl56_r272a
lvl57_r272b
lvl58_r272c
lvl59_r272d
lvl60_r272e
lvl61_r272f
lvl62_r272g
lvl63_r272h
lvl64_r272i
lvl65_r272j
lvl66_r272k
lvl67_r272l
lvl68_r272m
lvl69_r272n
lvl70_r272o
lvl71_r272p
lvl72_r272q
$s$fApplicativeRWST_$c<*>_r272u
$s$fApplicativeRWST_$cpure_r272v
lvl74_r272w
lvl75_r272x
lvl76_r272y
$s$fMonadRWST_$c>>_r272z
$s$fMonadRWST_$cfail_r272A
$s$fMonadRWST_$c>>=_r272B
lvl77_r272C
lvl78_r272D
lvl79_r272E
lvl80_r272F
lvl81_r272G
lvl82_r272H
$slesser1_r272S
lvl88_r272T
lvl89_r272U
$wcreate_r272V
lvl90_r272W
m2_r272X
$s$fMonadReaderT_$c>>_r272Y
$s$fMonadReaderT_$c>>=_r272Z
go10_r2730
$wpoly_create_r2731
lvl91_r2732
lvl92_r2733
lvl93_r2734
lvl94_r2735
lvl95_r2736
lvl96_r2737
lvl97_r2738
lvl98_r2739
lvl99_r273a
lvl100_r273b
lvl101_r273c
lvl102_r273d
lvl103_r273e
lvl104_r273f
lvl105_r273g
lvl106_r273h
lvl107_r273i
lvl108_r273j
lvl109_r273k
lvl110_r273l
lvl111_r273m
lvl112_r273n
lvl113_r273o
lvl114_r273p
lvl115_r273q
lvl116_r273r
lvl117_r273s
lvl118_r273t
lvl119_r273u
lvl120_r273v
lvl121_r273w
lvl122_r273x
lvl123_r273y
lvl124_r273z
$wpoly_create1_r273A
lvl125_r273B
lvl126_r273C
lvl127_r273D
lvl128_r273E
lvl129_r273F
lvl130_r273G
lvl131_r273H
lvl132_r273I
lvl133_r273J
lvl134_r273K
lvl135_r273L
$wlvl_r273M
lvl136_r273N
$wlvl1_r273O
lvl137_r273P
$wlvl2_r273Q
lvl138_r273R
$wlvl3_r273S
lvl139_r273T
$wlvl4_r273U
lvl140_r273V
$wlvl5_r273W
lvl141_r273X
$wlvl6_r273Y
lvl142_r273Z
lvl143_r2740
lvl144_r2741
lvl145_r2742
lvl146_r2743
lvl147_r2744
lvl148_r2745
lvl149_r2746
lvl150_r2747
lvl151_r2748
lvl152_r2749
lvl153_r274a
lvl154_r274b
$s$fFunctorReaderT_$cfmap_r274c
$s$fFunctorReaderT_$c<$_r274d
lvl155_r274e
lvl156_r274f
$s$fApplicativeReaderT_$c<*>_r274g
$s$fMonadReaderT_$creturn_r274h
$s$fMonadReaderT_$cfail_r274i
lvl157_r274j
lvl158_r274k
lvl159_r274l
lvl160_r274m
$d~_r274n
lvl161_r274p
lvl162_r274q
lvl163_r274s
lvl164_r274t
lvl165_r274v
lvl166_r274w
lvl167_r274y
lvl168_r274z
lvl169_r274B
lvl170_r274C
lvl171_r274E
lvl172_r274F
lvl173_r274H
lvl174_r274I
lvl175_r274K
lvl176_r274L
lvl177_r274N
lvl178_r274O
lvl179_r274Q
lvl180_r274R
lvl181_r274T
lvl182_r274U
lvl183_r274V
lvl184_r274W
lvl185_r274X
lvl186_r274Y
lvl187_r274Z
lvl188_r2750
lvl189_r2751
lvl190_r2752
lvl191_r2753
lvl192_r2754
lvl193_r2755
lvl194_r2756
lvl195_r2757
lvl196_r2758
lvl197_r2759
lvl198_r275a
lvl199_r275b
lvl200_r275c
lvl201_r275d
lvl202_r275e
lvl203_r275f
lvl204_r275g
lvl205_r275h
lvl206_r275i
lvl207_r275j
lvl208_r275k
lvl209_r275l
lvl210_r275m
lvl211_r275n
lvl212_r275o
lvl213_r275p
lvl214_r275q
lvl215_r275r
lvl216_r275s
lvl217_r275t
lvl218_r275u
lvl219_r275v
lvl220_r275w
ww1_r275x
ww2_r275y
lvl221_r275z
ww3_r275A
lvl222_r275B
pre_r275C
x_s27MP
eta_s27MQ
eta1_s27MR
ds_s27MS
ds1_s27MT
ds2_s27MU
ds3_s27MV
goal_s27MW
prxy'_s27MX
sat_s27MY
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/18918Potential for FastString uniques clashing with others2020-11-10T21:10:15ZBen GamariPotential for FastString uniques clashing with othersCurrently the `getUnique` implementation for `FastString` derives the unique from a sequential counter (starting at 0) associated with the global `FastStringTable`. One can argue that this is okay since the `\x00` unique tag isn't used b...Currently the `getUnique` implementation for `FastString` derives the unique from a sequential counter (starting at 0) associated with the global `FastStringTable`. One can argue that this is okay since the `\x00` unique tag isn't used by any `UniqueSupply`. However, if we allocate allocate enough `FastString`s we will overflow the zero-tag into regions of the tag-space used by other `UniqueSupply`s. This will result in unique collisions.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18822GHC panics on TH/QQ splice with external linkage present2020-11-09T14:07:14ZdminuosoGHC panics on TH/QQ splice with external linkage present## Summary
GHC panics during module linking when TH/QQ is spliced. The module defining the TH/quoter must depend on another module of the same package, that has some external linkage.
Added: The behavior affects template haskell as wel...## Summary
GHC panics during module linking when TH/QQ is spliced. The module defining the TH/quoter must depend on another module of the same package, that has some external linkage.
Added: The behavior affects template haskell as well as QQ. See branch `th` in the test repo
## Steps to reproduce
Clone and build:
https://gitlab.haskell.org/dminuoso/panic-testcase
## Module Diagram
```
Mod (splices TH/QQ)
|
|
v
QQ (defines TH/QQ)
|
|
v
Ext (external linkage)
```
```
$ cabal v2-build
Build profile: -w ghc-8.10.2 -O1
In order, the following will be built (use -v for more details):
- panic-testcase-0.1.0.0 (lib) (first run)
Preprocessing library for panic-testcase-0.1.0.0..
Building library for panic-testcase-0.1.0.0..
compile: input file lib/Other.hs
[3 of 4] Compiling Other ( lib/Other.hs, /home/dminuoso/wobcom/projects/panic-testcase/dist-newstyle/build/x86_64-linux/ghc-8.10.2/panic-testcase-0.1.0.0/build/Other.o, /home/dminuoso/wobcom/projects/panic-testcase/dist-newstyle/build/x86_64-linux/ghc-8.10.2/panic-testcase-0.1.0.0/build/Other.dyn_o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.10.2:
Loading temp shared object failed: /run/user/1000/ghc29723_0/libghc_1.so: undefined symbol: crypt
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Environment
* GHC version used:
- 8.10.2
- 8.10.1
- 8.8.4
- 8.6.5
Optional:
* Operating System: NixOS
* System Architecture: AMD64
https://gitlab.haskell.org/ghc/ghc/-/issues/18293Dynamic linker not initialised2020-11-05T08:26:52ZreallymemorableDynamic linker not initialised## Summary
Got this error in VSCode:
""panic! (the 'impossible' happened)\n (GHC version 8.6.5 for x86_64-unknown-linux):\n\tDynamic linker not initialised\n\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n""...## Summary
Got this error in VSCode:
""panic! (the 'impossible' happened)\n (GHC version 8.6.5 for x86_64-unknown-linux):\n\tDynamic linker not initialised\n\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n""
There are other bug reports in here with people who encountered the same bug and replies saying it is fixed. Not sure why I would still encounter it.
## Steps to reproduce
Attempting to use HIE with ghc865.
## Expected behavior
Not sure how to answer this.
## Environment
* GHC version used:
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/18812Typechecking the same module concurrently can result in a race condition2020-10-07T11:54:33ZZubinTypechecking the same module concurrently can result in a race conditionSometimes, `ghcide` would attempt to typecheck the same module concurrently(using the same HscEnv). This lead to [strange errors](https://github.com/haskell/ghcide/issues/614) when the module used TH and the `newName` function.
The [exa...Sometimes, `ghcide` would attempt to typecheck the same module concurrently(using the same HscEnv). This lead to [strange errors](https://github.com/haskell/ghcide/issues/614) when the module used TH and the `newName` function.
The [example](https://github.com/haskell/ghcide/commit/985268dec97783b44d0339bf32d0cf084b903410) that reproduces the bug uses `newName` to generate a data constructor name.
The implementation of `newName` is the following, from `GHC/Tc/Gen/Splice.hs`
```haskell
instance TH.Quasi TcM where
qNewName s = do { u <- newUnique
; let i = toInteger (getKey u)
; return (TH.mkNameU s i) }
```
The data constructor gets a new, distinct `Unique` during each of the concurrent typechecks. However, only one of these ends up in the `NameCache`, leading to the `tcg_type_env`(and possibly other things) having an inconsistent state.
From one of the typechecks, we get the following type env:
```
[a46h :-> Data constructor fake_uid:B.A{d a46h}, ...
```
From the other, we got:
```
[a46I :-> Data constructor fake_uid:B.A{d a46I}, ...
```
When we called `makeSimpleDetails` on the result of one of these typechecks, this is the type-env we ended up with was:
```
[a46I :-> Data constructor fake_uid:B.A{d a46h}, ...
```
(Note the unique `a46I` maps to symbol with unique `a46h`)
The unique associated with `B.A` in the `NameCache` is `a46h`
Finally, when type-checking a dependent module which tries to use the data constructor `B.A`, we get
```
Can't find interface-file declaration for data constructor fake_uid:B.A{d a46h}
```
This issue has been fixed in `ghcide` by ensuring we never typecheck the same module concurrently.
I'm not sure what ghc should do here. We can't consult the `NameCache` in `qNewName` because names generated via that method can't capture already existing names. Perhaps all that is needed is to document this behavior with a Note/comment somewhere. Another fix could be a module-keyed lock on the `NameCache`, but I doubt the cost is worth it for such a rare and easily worked around issue.https://gitlab.haskell.org/ghc/ghc/-/issues/18797ghc-iserv-dyn: loadObj: failed to mmap() memory below 2Gb on aarch642020-10-05T18:53:59ZIfSixWasNineghc-iserv-dyn: loadObj: failed to mmap() memory below 2Gb on aarch64## Summary
ghc-iserv-dyn fails with issue indicated in the title when cross compiling project comprising template haskell dependency.
## Steps to reproduce
try to cross compile attached [Main.hs](/uploads/b1a23d60284910301d076741c6b...## Summary
ghc-iserv-dyn fails with issue indicated in the title when cross compiling project comprising template haskell dependency.
## Steps to reproduce
try to cross compile attached [Main.hs](/uploads/b1a23d60284910301d076741c6badb39/Main.hs) minimum source that has dependency on wai-app-static package using template haskell.
## Expected behavior
cross compiling fails with indicated issue as listed in attached [ghc_output.txt](/uploads/fd70b78cb51d055e0327f60f852f9955/ghc_output.txt) file.
## Environment
* GHC version used: 8.10.2
Optional:
* Operating System: Ubuntu 20.04.1 LTS on build host running GHC - Debian GNU/Linux 10 on target host running ghc-iserv-dyn
* System Architecture: x86_64-linux on build host - arch64-linux on target host
* Hardware: Dell XPS 13 9360 with 8GB memory build host - Boundary Devices i.MX8MQ Nitrogen8M with 2GB memory target host
* Cross compiling script peculiarities:
- the stack tool has been used for cross compiling
- for this purpose the following scripts have been created/replaced in the standard build system on build host:
-- in directory ~/.stack/programs/aarch64-linux/ghc-8.10.2/bin/ [ghc](/uploads/9c6cf103f5d3664be689ec85c5748acb/ghc)
-- Note that instance_host and instance_target parameters of script need to be adapted to test environment.
-- in directory ~/.stack/programs/aarch64-linux/ghc-8.10.2/lib/aarch64-linux-gnu-ghc-8.10.2/bin [ghc-iserv-dyn](/uploads/bb406b3fc9c3b7617f7da5f82d1bc7af/ghc-iserv-dyn)
.. Note that target parameter of script needs to be adapted to test environment.
* General remarks:
- This issue does not occur for the same environment conditions when using GHC 8.8.3.
- The "-xm" RTS flag for working around the issue as indicated in the build output seems not to be supported.
- Any workaround for cross compiling template haskell modules using GHC 8.10.2 is highly appreciated.https://gitlab.haskell.org/ghc/ghc/-/issues/18725GHC panic: tcLookupGlobalOnly2020-09-30T20:59:32ZVladislav ZavialovGHC panic: tcLookupGlobalOnly```haskell
{-# LANGUAGE ExplicitForAll, KindSignatures, StandaloneKindSignatures,
DataKinds, GADTs #-}
module T18725 where
import Data.Kind (Type)
type U :: Type
data U where P :: forall u. E u -> U
data E (u :: U)
```
T...```haskell
{-# LANGUAGE ExplicitForAll, KindSignatures, StandaloneKindSignatures,
DataKinds, GADTs #-}
module T18725 where
import Data.Kind (Type)
type U :: Type
data U where P :: forall u. E u -> U
data E (u :: U)
```
This program results in a panic with GHC HEAD:
```
GHCi, version 9.1.0.20200918: https://www.haskell.org/ghc/ :? for help
Prelude> :load T18725.hs
[1 of 1] Compiling T18725 ( T18725.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 9.1.0.20200918:
tcLookupGlobalOnly
U
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:185:37 in ghc:GHC.Utils.Pa
nic
pprPanic, called at compiler/GHC/Tc/Utils/Env.hs:256:35 in ghc:GHC.Tc.Utils.En
v
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
However, it gives a reasonable error message with GHC 8.10:
```
GHCi, version 8.10.1: https://www.haskell.org/ghc/ :? for help
Prelude> :load T18725.hs
[1 of 1] Compiling T18725 ( T18725.hs, interpreted )
T18725.hs:10:14: error:
• Type constructor ‘U’ cannot be used here
(it is defined and used in the same recursive group)
• In the kind ‘U’
|
10 | data E (u :: U)
| ^
Failed, no modules loaded.
```
The regression appears related to `StandaloneKindSignatures`, as removing the `type U :: Type` line makes the issue go away.https://gitlab.haskell.org/ghc/ghc/-/issues/18507Ghc crashes on start2020-07-27T16:31:29Zk0inworkGhc crashes on start## Summary
GHC crashes on start
Message:
localhost:~$ ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
ghc: internal error: createAdjustor: failed to allocate memory
(GHC version 8.0.2 for arm_...## Summary
GHC crashes on start
Message:
localhost:~$ ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
ghc: internal error: createAdjustor: failed to allocate memory
(GHC version 8.0.2 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
## Steps to reproduce
Install on android userland application
Install ubuntu
Install haskell-platform
Run ghci
Please provide a set of concrete steps to reproduce the issue.
## Expected behavior
What do you expect the reproducer described above to do?
## Environment
* GHC version used:
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/18456"equirecursive" type family leads to stack overflow in ghci2020-07-17T13:59:54ZXia Li-yao"equirecursive" type family leads to stack overflow in ghci## Summary
Trying to typecheck a term using a (silly) type family such that `T ~ Maybe T` leads to a stack overflow (instead of a proper type error from reaching the max reduction depth, if this is to be an error at all).
## Steps to r...## Summary
Trying to typecheck a term using a (silly) type family such that `T ~ Maybe T` leads to a stack overflow (instead of a proper type error from reaching the max reduction depth, if this is to be an error at all).
## Steps to reproduce
```
> :set -XTypeFamilies -XUndecidableInstances
> type family T where T = Maybe T
> :t Nothing @T
Nothing @T*** Exception: stack overflow
```
(where the exception takes a few seconds to appear)
Compare that output to this variant that immediately produces a proper type error:
```
> :t Nothing @T :: T
<interactive>:5:1 error:
...
```
## Expected behavior
Either a success (`Nothing @T` has type `Maybe T` without requiring any type conversion), or a type error instead of an internal exception.
## Environment
* GHC version used: 8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/18186GHC crash "urk! lookup local fingerprint"2020-06-24T19:31:34ZAdrien SuréeGHC crash "urk! lookup local fingerprint"## Summary
The following code crashes when compiled with GHC 8.8.3:
```haskell
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeFamilies #-}
module Main (main) where
import Data.Kind...## Summary
The following code crashes when compiled with GHC 8.8.3:
```haskell
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeFamilies #-}
module Main (main) where
import Data.Kind (Type)
type family F :: k -> Type
type family B (a :: k) (b :: k) :: k
main :: IO ()
main =
\(_ :: F n) -> (undefined :: B n 1)
-- this should raise an error, `B n 1' is not a type
```
Output:
```
[1 of 1] Compiling Main ( Main.hs, Main.o ) [Optimisation flags changed]
ghc: panic! (the 'impossible' happened)
(GHC version 8.8.3 for x86_64-unknown-linux):
urk! lookup local fingerprint
main
[]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable
pprPanic, called at compiler/iface/MkIface.hs:535:37 in ghc:MkIface
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Steps to reproduce
Run `ghc -O2 Main.hs`
## Expected behavior
GHC should not crash and should output the correct error.
## Environment
* GHC version used: 8.8.3
* Operating System: GNU/Linux
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/18152Combination of unboxed sums and unsafeCoerce# causes compiler panics2020-05-09T18:15:21ZÖmer Sinan AğacanCombination of unboxed sums and unsafeCoerce# causes compiler panicsIf you compile this nonsensical program:
```haskell
{-# LANGUAGE UnboxedSums, UnboxedTuples, MagicHash #-}
import Unsafe.Coerce
import GHC.Prim
main = do
let x = (# 1 | #) :: (# Int | Int# #)
let y = unsafeCoerce# x :: (# (# Int, ...If you compile this nonsensical program:
```haskell
{-# LANGUAGE UnboxedSums, UnboxedTuples, MagicHash #-}
import Unsafe.Coerce
import GHC.Prim
main = do
let x = (# 1 | #) :: (# Int | Int# #)
let y = unsafeCoerce# x :: (# (# Int, Int #) | Int# #)
case y of
(# (# i1, i2 #) | #) -> do print i1; print i2
(# | i #) -> return ()
```
GHC HEAD current panics in `GHC.Cmm.Liveness`:
```
{-# LANGUAGE UnboxedSums, UnboxedTuples, MagicHash #-}
import Unsafe.Coerce
import GHC.Prim
main = do
let x = (# 1 | #) :: (# Int | Int# #)
let y = unsafeCoerce# x :: (# (# Int, Int #) | Int# #)
case y of
(# (# i1, i2 #) | #) -> do print i1; print i2
(# | i #) -> return ()
```
While this program doesn't make any sense, I'm not sure if GHC should panic this way (instead of with rejecting the program with a friendly error message) when provided a nonsensical program.
I think it's also possible that this is an actual bug in the code generator.https://gitlab.haskell.org/ghc/ghc/-/issues/14987Memory usage exploding for complex pattern matching2020-05-02T22:45:07ZvmiraldoMemory usage exploding for complex pattern matchingIt seems like complex pattern matching is consuming a prohibitive amount of memory. From a discussion in ghc-devs, [https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html](https://mail.haskell.org/pipermail/ghc-devs/2018-Marc...It seems like complex pattern matching is consuming a prohibitive amount of memory. From a discussion in ghc-devs, [https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html](https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html), the exhaustiveness checker could be the culprit.
We have tried with 7.10.3, 8.0.2, 8.4.1 and ghc-HEAD. They show similar results.
The "-fmax-pmchecker-iterations=0" option seems to help slightly. Bigger cases
will run out of memory even with the option enabled.
I'm attaching a "minimal" example to help diagnosing. The majority of the
code has been generated by Template Haskell.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Memory usage exploding for complex pattern matching","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems like complex pattern matching is consuming a prohibitive amount of memory. From a discussion in ghc-devs, [https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html], the exhaustiveness checker could be the culprit. \r\n\r\nWe have tried with 7.10.3, 8.0.2, 8.4.1 and ghc-HEAD. They show similar results.\r\n\r\nThe \"-fmax-pmchecker-iterations=0\" option seems to help slightly. Bigger cases\r\nwill run out of memory even with the option enabled.\r\n\r\nI'm attaching a \"minimal\" example to help diagnosing. The majority of the\r\ncode has been generated by Template Haskell.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/17942Backpack fails with: Can't find interface-file declaration2020-03-22T17:51:26ZAndrew MartinBackpack fails with: Can't find interface-file declaration## Summary
When using an indefinite module to fill in a signature, backpack succeeds. However, it fails later during instantiation with:
```
typecheckIfaceForInstantiate
Declaration for write#:
Can't find interface-file declaration f...## Summary
When using an indefinite module to fill in a signature, backpack succeeds. However, it fails later during instantiation with:
```
typecheckIfaceForInstantiate
Declaration for write#:
Can't find interface-file declaration for type constructor or class M
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
```
At https://github.com/andrewthad/vex-minimal-reproducer, there is a somewhat minimal reproducer. The repo also includes a readme with more detail about the motivation and some investigation of the error itself.
## Steps to reproduce
```
git clone https://github.com/andrewthad/vex-minimal-reproducer
cd vex-minimal-reproducer
cabal v2-build
```
## Expected behavior
The build should succeed.
## Environment
* GHC version used: 8.8.3, 8.10.1rc, HEAD
cc @ezyangEdward Z. YangEdward Z. Yang