September 2015 - ghc-tickets

[GHC] #10388: GHC panic when compiling Yesod app
by GHC 20 Oct '15

20 Oct '15

#10388: GHC panic when compiling Yesod app -------------------------------------+------------------------------------- Reporter: chfi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling a Yesod app, using 'yesod devel', GHC crashes with the following error: {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib, 5): Symbol not found: _adverzuGWP0VNzzhgmvBNANratclKO_SubscriptionType_zdfPersistFieldKey_closure Referenced from: /var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib Expected in: flat namespace in /var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib }}} Specifically, I'm using Yesod's mkPersist to create a data type, and it works fine, until I make said type an instance of FromJSON, in which case the above panic occurs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10390: Constraint order must match with RankNTypes
by GHC 20 Oct '15

20 Oct '15

#10390: Constraint order must match with RankNTypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the following code, GHC will not compile unless the constraints on the higher-rank function have the same *order* as the method declaration in `ApPair`. {{{#!hs {-# LANGUAGE RankNTypes #-} class ApPair r where apPair :: (forall a . (ApPair a, Num a) => Maybe a) -> Maybe r instance (ApPair a, ApPair b) => ApPair (a,b) where apPair = apPair' apPair' :: (ApPair b, ApPair c) => (forall a . (ApPair a, Num a) => Maybe a) -> Maybe (b,c) apPair' f = let (Just a) = apPair f (Just b) = apPair f in Just $ (a, b) }}} That is, the following does *not* compile: {{{#!hs apPair' :: (ApPair b, ApPair c) => (forall a . (Num a, ApPair a) => Maybe a) -> Maybe (b,c) apPair' f = let (Just a) = apPair f (Just b) = apPair f in Just $ (a, b) }}} GHC probably shouldn't care about lexical matching when checking constraints. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8648: Initialization of C statics broken in threaded runtime
by GHC 20 Oct '15

20 Oct '15

#8648: Initialization of C statics broken in threaded runtime ------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider a tiny package `static-value`, consisting of one Haskell file {{{ foreign import ccall unsafe "returnStaticValue" c_returnStaticValue :: IO CInt printStaticValue :: IO () printStaticValue = print =<< c_returnStaticValue }}} and one corresponding C file {{{ static int theStaticValue = 0; int returnStaticValue() { // Modify the static so the C compiler doesn't optimize it away return theStaticValue++; } }}} (test case is attached). If we call `printStaticValue` using the GHC API: {{{ runGhc (Just libdir) $ do flags0 <- getSessionDynFlags void $ setSessionDynFlags flags0 { hscTarget = HscInterpreted , ghcLink = LinkInMemory , ghcMode = CompManager } setContext $ [ IIDecl $ simpleImportDecl $ mkModuleName "StaticValue" ] _ <- runStmt "StaticValue.printStaticValue" RunToCompletion }}} then we see "0", as expected. However, if we compile this code using the threaded runtime, and we wrap the above code in a call to either `forkIO` or `forkOS`, then we see a different value printed (-907777, whatever that value is). Some notes: * I have been unable to reproduce this bug without using GHC as API; in particular, calling `printStaticValue` directly, wrapped in `forkIO` or `forkOS` or not, always works as expected. * If I change the initialization value of `staticValue` from 0 to anything else (say, 1234), we always get the right answer, never the uninitialized value. Presumably this is because non-zero values require some explicit code to be run (and it does get run), while a zero value gets initialized differently (and apparently, that's where the bug is). * I have reproduced this bug in both ghc 7.4 and 7.7.20131227. This ticket is the result of tracking down a problem with calling `createProcess` from within the GHC API, which would cause the parent process to stall. As it turns out, `runProcess.c` (from the `process` library) declares a `static long max_fd = 0`, and in `runInteractiveProcess` checks for this value to be 0, and if it is, does a syscall to figure out what the maximum FD is. But since this static does not get initialized properly (the bug reported in this ticket), it gets left at its (random? but always the same) value (281474975802879), so that the child process proceeds to close rather too many file descriptors (if close_fds was set to True) and the parent stalls. Indeed, changing the initialization to `static long max_fd = -1` (and adjusting the later check for zero accordingly) fixes this (so this is a viable workaround in `process` if we cannot track down the bug in GHC). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10650: Can't define GHCi :def macro with NoImplicitPrelude on
by GHC 20 Oct '15

20 Oct '15

#10650: Can't define GHCi :def macro with NoImplicitPrelude on -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8640 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHCi is unusually prohibitive in typechecking {{{:def}}} macros when {{{NoImplicitPrelude}}} is enabled. Here's an example to illustrate what I mean: {{{ $ ghci -XNoImplicitPrelude GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help λ> :def pf \str -> Prelude.return Prelude.$ ":! pointfree \"" Prelude.++ str Prelude.++ "\"" <interactive>:1:111: Not in scope: type constructor or class ‘String’ <interactive>:1:121: Not in scope: type constructor or class ‘IO’ <interactive>:1:124: Not in scope: type constructor or class ‘String’ }}} I can understand the functions being out-of-scope when {{{NoImplicitPrelude}}} is on, but the type errors don't make any sense to me, especially since {{{:t}}} seems to pick up on the types just fine: {{{ λ> :t Prelude.return Prelude.return :: GHC.Base.Monad m => a -> m a λ> :t "\"" "\"" :: [GHC.Types.Char] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs
by GHC 19 Oct '15

19 Oct '15

#9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Like many programming language environments, GHC offers a handy `-e` option for evaluating an expression, then returning to the shell. {{{ $ ghc -e '2 + 2' 4 }}} One would expect the interpreter, GHCi, to offer a similar flag, but it surprisingly rejects it. {{{ ghci -e '2 + 2' ghc: on the commandline: cannot use `--interactive' with `-e' Usage: For basic information, try the `--help' option. }}} I think this behavior is quite unintuitive--when I pass `-e <exp>` to ghci, or pass `--interactive -e <exp>` to ghc, I expect the expression to be evaluated as the leading expression in an interactive interpreter session. Could we please tweak ghc like this to make it slightly more intuitive when these flags are used together? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression
by GHC 17 Oct '15

17 Oct '15

#10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- At the end is a log of my ghci session reproducing the issue. It is expected that the splice should succeed, but GHC complains "Illegal data constructor name: `fromList' ... When splicing a TH expression". Full definitions being used can be found at http://hackage.haskell.org/package/regex-tdfa-quasiquoter-0.2.0.0 . Briefly, this is the splice being used. {{{#!hs [e|patternToRegex $patternExp $compOptsExp $execOptsExp|] where patternExp = dataToExpQ (const Nothing) pattern compOptsExp = dataToExpQ (const Nothing) compOpts execOptsExp = dataToExpQ (const Nothing) execOpts }}} Data and Typeable instances are derived (using -XStandaloneDeriving -XDeriveDataTypeable) as orphan instances in the Internal module. The issue occurs when using bracket expressions (in POSIX regular expressions). There may be other cases but I have not uncovered them. {{{ > ghci GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. >>> :set -XQuasiQuotes >>> import Text.Regex.TDFA.QuasiQuoter >>> :t [re|;[a]|] Loading package transformers-0.3.0.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package regex-base-0.93.2 ... linking ... done. Loading package text-1.2.0.3 ... linking ... done. Loading package parsec-3.1.9 ... linking ... done. Loading package regex-tdfa-1.2.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package regex-tdfa-quasiquoter-0.2.0.0 ... linking ... done. <interactive>:1:5: Illegal data constructor name: `fromList' When splicing a TH expression: Text.Regex.TDFA.TDFA.patternToRegex (GHC.Tuple.(,) (Text.Regex.TDFA.Pattern.POr ((GHC.Types.:) (Text.Regex.TDFA.Pattern.PConcat ((GHC.Types.:) (Text.Regex.TDFA.Pattern.PAny (Text.Regex.TDFA.Common.DoPa 1) (Text.Regex.TDFA.Pattern.PatternSet (Data.Maybe.Just (Data.Set.Base.fromList ((GHC.Types.:) 'a' GHC.Types.[]))) Data.Maybe.Nothing Data.Maybe.Nothing Data.Maybe.Nothing)) GHC.Types.[])) GHC.Types.[])) (GHC.Tuple.(,) 0 (Text.Regex.TDFA.Common.DoPa 1))) (Text.Regex.TDFA.Common.CompOption GHC.Types.True GHC.Types.True GHC.Types.True GHC.Types.True GHC.Types.False) (Text.Regex.TDFA.Common.ExecOption GHC.Types.True) >>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10911: Allow left ∨ (+++) as minimal definition of ArrowChoice instance
by GHC 16 Oct '15

16 Oct '15

#10911: Allow left ∨ (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: | Owner: mfdyck.google | Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Add default definitions of left, right in terms of (+++) to let one define an ArrowChoice instance in terms of (+++) rather than left, which is sometimes more elegant or convenient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10882: Fix target tripe for Arm
by GHC 16 Oct '15

16 Oct '15

#10882: Fix target tripe for Arm -----------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------- LLVM IR code generated by GHC on Arm (Debian) uses a target triple of "arm-linux-gnueabi" which according the LLVM people is something like ARMv4 with software float. Clang on the other hand generates IR code with a target triple of "armv6 -linux-gnueablhf" which is ARMv6 and hardware float so it works on the original Raspberry Pi. GHC should either use the same target triple as Clang or at least make it configurable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10888: ghci crashes
by GHC 16 Oct '15

16 Oct '15

#10888: ghci crashes ------------------------------------+------------------------------- Reporter: parsifal9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ------------------------------------+------------------------------- Hi all, the compiler was installed from the file ghc_7.10.2-2_armhf.deb localhost: arch armv7l {{{#!hs localhost: ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :l Course/List.hs [1 of 2] Compiling Course.Core ( Course/Core.hs, interpreted ) [2 of 2] Compiling Course.List ( Course/List.hs, interpreted ) Ok, modules loaded: Course.List, Course.Core. *Course.List> (1:. 2:. Nil) ++ (1:. 2:. Nil) [1,2,1,2Segmentation fault (core dumped) }}} The files Core.hs and List.hs are attached. I dont know how to cut the example down any smaller. Sorry. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10888> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10714: After implementing new installed package ID (hash of sdist), get rid of package keys
by GHC 15 Oct '15

15 Oct '15

#10714: After implementing new installed package ID (hash of sdist), get rid of package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.10.2 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC tracking bug for https://github.com/haskell/cabal/issues/2745 Externally, GHC's flags do not have to change much; a user simply passes the installed package ID to the flag currently named `-this-package-key` (but perhaps we should rename this.) Internally, if we can assume that `PackageKey == InstalledPackageId`, we can do away with the `InstalledPackageId` map and get rid of the level of indirection between the bin-pkg-db (which records installed package IDs`) and GHC's guts (which record package keys). Blocked on Cabal not actually using ABI hashes to identify packages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5