September 2017 - ghc-tickets

[GHC] #12152: panic: Loading temp shared object failed
by GHC 03 Jun '18

03 Jun '18

#12152: panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've attached a no-Haskell-code project that fails when I run `cabal repl` with the following: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc60744_0/libghc_1.so: undefined symbol: _ZN2Zq1qE }}} Building the project works fine, so the problem seems to be (only) with dynamic linking. The issue can be resolved by swapping the order of the .cpp files in the cabal file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9247: Document -XDatatypeContexts in flag reference
by GHC 03 Jun '18

03 Jun '18

#9247: Document -XDatatypeContexts in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It may be a deprecated feature, but it still exists and should be listed. I can do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness?
by GHC 03 Jun '18

03 Jun '18

#11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10.2 reports inaccessible branches as a type error, and I think this is really a bug. First, the implicit thinking seems to be "why would a user want to write inaccessible cases, they'd be crazy!". But that only applies to human-written code. Program generators can have a great deal of trouble avoiding this error, unless they replicate the GHC type checker to predict the problem and prune branches. (That's why we are hitting this error and are stuck.) Second, it seems like this is a problem for type soundness. See the attached program where "step1" typechecks but "step2" does not. And yet, the operational semantics should allow step1 to reduce to step2. Indeed, in the "GADTs meet their match" paper it seems like the intent was to warn for these inaccessible cases, not error. For example, the paper contains the language: "If we warn that a right-hand side of a non-redundant clause is inaccessible," -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #14059: COMPLETE sets don't work at all with data family instances
by GHC 03 Jun '18

03 Jun '18

#14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code that uses a pattern synonym for a data family GADT constructor, along with a corresponding `COMPLETE` set: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data family Sing (a :: k) data instance Sing (z :: Bool) where SFalse :: Sing False STrue :: Sing True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => Sing z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: Sing (z :: Bool) -> Bool wibble STrue = True wobble :: Sing (z :: Bool) -> Bool wobble STooGoodToBeTrue = True }}} However, if you compile this, you might be surprised to find out that GHC only warns about `wibble` being non-exhaustive: {{{ $ ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 23 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ }}} I believe the use of data families is the culprit here, since a variant of this program which doesn't use data families correctly warns for both `wibble` and `wobble`: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Foo where data SBool (z :: Bool) where SFalse :: SBool False STrue :: SBool True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => SBool z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: SBool z -> Bool wibble STrue = True wobble :: SBool z -> Bool wobble STooGoodToBeTrue = True }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:20:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 20 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ Foo.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wobble’: Patterns not matched: SFalse | 23 | wobble STooGoodToBeTrue = True | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13777: Poor error message around CUSKs
by GHC 02 Jun '18

02 Jun '18

#13777: Poor error message around CUSKs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: TypeInType, | Operating System: Unknown/Multiple CUSKs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While typing up comment:7:ticket:13761, I came across a poor error message around CUSKs. {{{ data Proxy (a :: k) = P data S :: forall k. Proxy k -> Type where MkS :: S (P :: Proxy Maybe) }}} produces {{{ You have written a *complete user-suppled kind signature*, but the following variable is undetermined: k0 :: * Perhaps add a kind signature. Inferred kinds of user-written variables: }}} That promised list of the kinds of user-written variables is empty. Either GHC should find something to print (like `k :: k0`, perhaps) or omit the header. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage
by GHC 02 Jun '18

02 Jun '18

#12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ----------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This seems to be a build regression from ghc-8.0.1. The ghc.1 manpage was not installed for the 8.0.2 RC1 build. I reported this in mail earlier and unfortunately in the meantime lost the buildlogs on Fedora Copr, but since the upstream binary tarballs for Linux also don't seem to contain ghc.1 either it should not be too hard to reproduce. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2
by GHC 01 Jun '18

01 Jun '18

#13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I notice that buildbots were having a hard-time building GHC 8.2 snapshots... so I investigated... One thing that jumped at me was the memory usage while compiling DynFlags which is the worst memory-offender with 4777MiB of resident size: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.2.0.201 70313 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen - icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompi ler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -pa ckage-id directory-1.3.0.2 -package-id process-1.4.3.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id fil epath-1.4.1.1 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc- boot-8.2.0.20170313 -package-id ghc-boot-th-8.2.0.20170313 -package-id ghci-8.2.0.20170 313 -package-id hoopl-3.10.2.2 -package-id unix-2.7.2.1 -package-id terminfo-0.4.0.2 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-t iming -O2 -no-user-package-db -rtsopts -Wnoncanonical-monad- instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/main/DynFlags.hs -o compiler/stage2/build/DynFlags.o -dyno compiler/stage2/build/DynFlags.dyn_o }}} {{{ <<ghc: 63014533832 bytes, 4032 GCs, 395131448/1973969928 avg/max bytes residency (24 samples), 4777M in use, 0.000 INIT (0.000 elapsed), 32.207 MUT (33.221 elapsed), 26.682 GC (26.685 elapsed) :ghc>> }}} Then I did two clean full builds of the `ghc-8.0` and `ghc-8.2` branch, and collected the -Rghc-timings output into simple 3-columns .csv files; Here's are the respective top-12 entries for GHC 8.0 and GHC 8.2 respectively: {{{#!bash $ sort -t, -k2n build.80.csv | tail -n12 "inplace/bin/ghc-stage1",560,compiler/stage2/build/TcRnDriver.o "inplace/bin/ghc-stage1",572,compiler/stage2/build/TcRnDriver.p_o "inplace/bin/ghc-stage1",572,compiler/stage2/build/TcSplice.o "inplace/bin/ghc-stage1",847,compiler/stage2/build/OptCoercion.p_o "/opt/ghc/bin/ghc",979,compiler/stage1/build/OptCoercion.o "/opt/ghc/bin/ghc",1036,compiler/stage1/build/DynFlags.o "/opt/ghc/bin/ghc",1040,compiler/stage1/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1119,compiler/stage2/build/DynFlags.p_o "inplace/bin/ghc-stage1",1123,compiler/stage2/build/DynFlags.o "inplace/bin/ghc-stage1",1178,compiler/stage2/build/OptCoercion.o "inplace/bin/ghc-stage1",1233,compiler/stage2/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1282,compiler/stage2/build/X86/CodeGen.p_o }}} {{{#!bash $ sort -t, -k2n build.82.csv | tail -n12 "inplace/bin/ghc-stage1",891,compiler/stage2/build/CmmParse.p_o "/opt/ghc/bin/ghc",1053,compiler/stage1/build/DynFlags.o "/opt/ghc/bin/ghc",1058,compiler/stage1/build/OptCoercion.o "inplace/bin/ghc-stage1",1284,compiler/stage2/build/HsExpr.p_o "inplace/bin/ghc-stage1",1313,compiler/stage2/build/HsExpr.o "/opt/ghc/bin/ghc",1394,compiler/stage1/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1495,compiler/stage2/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1605,compiler/stage2/build/X86/CodeGen.p_o "inplace/bin/ghc-stage1",1620,compiler/stage2/build/OptCoercion.o "inplace/bin/ghc-stage1",1733,compiler/stage2/build/OptCoercion.p_o "inplace/bin/ghc-stage1",3989,compiler/stage2/build/DynFlags.p_o "inplace/bin/ghc-stage1",4777,compiler/stage2/build/DynFlags.o }}} What's apparent from this data: - GHC stage0 (which was GHC 8.0.2) is able to build DynFlags.o for GHC 8.0 and GHC 8.2 w/ roughtly the same amount of max resident memory, i.e. 1 GiB - **GHC 8.2 stage1 however needs 4 times the amount of memory more than GHC 8.0 to build the same `DynFlags.hs` module!** -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59

[GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2
by GHC 01 Jun '18

01 Jun '18

#13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr [[https://mail.haskell.org/pipermail/ghc- devs/2017-May/014208.html|points out]] that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically while compilation time rose. {{{ GHC 8.0.2: <<ghc: 89544610040 bytes, 2301 GCs, 189183965/391103872 avg/max bytes residency (29 samples), 1075M in use, 0.001 INIT (0.001 elapsed), 55.747 MUT (61.520 elapsed), 23.276 GC (23.278 elapsed) :ghc>> GHC 8.2.1: <<ghc: 115210990008 bytes, 6383 GCs, 116487828/234031864 avg/max bytes residency (77 samples), 670M in use, 0.001 INIT (0.000 elapsed), 64.154 MUT (68.262 elapsed), 37.114 GC (37.077 elapsed) :ghc>> }}} == Reproducing == {{{ $ cabal unpack regex-tdfa-1.2.2 $ cd regex-tdfa-1.2.2 $ cabal install --only-dependencies $ cabal configure $ cabal build $ time ghc -idist/build/autogen -O2 Text/Regex/TDFA.hs \ -XMagicHash -XFlexibleInstances -XMultiParamTypeClasses \ -XRecursiveDo -XBangPatterns -XRankNTypes -XUnboxedTuples \ -XFlexibleContexts -XUnliftedFFITypes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9724: reexport IsList class from a trustworthy module
by GHC 31 May '18

31 May '18

#9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ==== Motivation GHC's Safe Haskell extension relies to a large extent on inferring safety of modules automatically. As a concrete example, [[http://hackage.haskell.org/package/data-default|data-default]] used to be inferred safe. This is no longer the case, because [[http://hackage.haskell.org/package/dlist-0.7.1|dlist-0.7.1]] added an {{{IsList}}} instance for difference lists. The only way to do that currently is to import the relevant parts of {{{GHC.Exts}}}, and that module is not safe. Of course the resulting non-safety of the {{{Data.DList}}} module can be fixed by adding a {{{TrustWorthy}}} pragma to the module and trusting the {{{dlist}}} package. But that is unsatisfactory, because there is nothing unsafe about providing an instance for the {{{IsList}}} class. This issue is bound to pop up in other packages as well. ==== Proposed Solution (this is one of many possibilities) Add a {{{GHC.Exts.Safe}}} module that is marked {{{TrustWorthy}}} and reexports the {{{IsList}}} class, and possibly other things from {{{GHC.Exts}}} that are safe to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9479: Report required constraints when reporting the type of a hole
by GHC 30 May '18

30 May '18

#9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: dominiquedevriese | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: holes | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For the following code {{{ module Test where test :: String test = show _h }}} GHC currently reports: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Applicable constraints: Show a0 Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11