November 2014 - ghc-tickets

[GHC] #9744: Make program name and project version configurable
by GHC 23 Dec '14

23 Dec '14

#9744: Make program name and project version configurable -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC uses `cProjectVersion` in a few places and `ghc` is hardcoded as the program name. This is used for example for determining the location of the user package database (`getAppUserDataDirectory "ghc"`) and the names of dynamic libraries. I've been working around this for GHCJS, but it requires copying quite a bit of code. I have a patch that adds the program name and version to `Settings` that I'll submit once I've tested GHCJS with HEAD. My patch just allows these settings to be changed by GHC API clients. However, we could also make GHC itself read its own values from the `settings` file. This way we could add a version tag to a GHC installation without recompiling, keeping its packages and package databases separate from existing ones. Let me know if there's any interest in this and I'll add it to the patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook
by GHC 23 Dec '14

23 Dec '14

#9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: GHC API | 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: -------------------------------------+------------------------------------- GHCJS has to jump through hoops to make annotations work and to get the necessary information for linking a TH splice. The main reason is that `hscCompileCoreExprHook` does not expose the `TcM` environment. Easiest fix would be to add {{{#!hs hscCompileCoreExprTcMHook :: HscEnv -> SrcSpan -> CoreExpr -> TcM HValue }}} to `Hooks`, but it'd be better to hook `runMeta` instead. Unfortunately `runMeta` is polymorphic, so it could be more tricky. I'm going to see if I can hook `runMeta` in a reasonable way, and if I run out of time for 7.10.1, send a patch with `hscCompileCoreExprTcMHook` instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations
by GHC 23 Dec '14

23 Dec '14

#9783: Pattern synonym matcher is unnecessarily strict on unboxed continuations -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: pattern synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Moderate (less | result at runtime than a day) | Test Case: Blocked By: | Blocking: Related Tickets: 9732 | Differential Revisions: -------------------------------------+------------------------------------- As discovered while investigating #9732, if you have something like {{{ {-# LANGUAGE PatternSynonyms, MagicHash #-} import GHC.Base pattern P = True f :: Bool -> Int# f P = 42# }}} `f` is compiled into {{{ Main.f :: GHC.Types.Bool -> GHC.Prim.Int# [LclIdX, Str=DmdType] Main.f = letrec { f_apU :: GHC.Types.Bool -> GHC.Prim.Int# [LclId, Str=DmdType] f_apU = \ (ds_dq1 :: GHC.Types.Bool) -> break<2>() let { fail_dq2 :: GHC.Prim.Void# -> GHC.Prim.Int# [LclId, Str=DmdType] fail_dq2 = \ (ds_dq3 [OS=OneShot] :: GHC.Prim.Void#) -> Control.Exception.Base.patError @ GHC.Prim.Int# "unboxed.hs:7:1-9|function f"# } in case fail_dq2 GHC.Prim.void# of wild_00 { __DEFAULT -> (case break<1>() 42 of wild_00 { __DEFAULT -> Main.$mP @ GHC.Prim.Int# ds_dq1 wild_00 }) wild_00 }; } in f_apU }}} Note how `fail_dq2` is applied on `void#` _before_ the pattern match, meaning the following expression: {{{ I# (f True) }}} will fail with {{{ *** Exception: unboxed.hs:7:1-9: Non-exhaustive patterns in function f }}} This is because the the type of `P`'s matcher, instantiated for its use in `f`, is {{{ $mP :: Bool -> Int# -> Int# -> Int# }}} so of course it is strict both on the success and the failure continuation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9732: Pattern synonyms and unboxed values
by GHC 23 Dec '14

23 Dec '14

#9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It's possible to declare a toplevel unboxed value with a pattern synonym, which causes a panic: {{{ {-# LANGUAGE PatternSynonyms, MagicHash #-} pattern P = 0# }}} (compare with error on `x = 0#`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9732> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #8650: Unexpected behaviour of import ccall "header.h function"
by GHC 21 Dec '14

21 Dec '14

#8650: Unexpected behaviour of import ccall "header.h function" ------------------------------------+-------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- When I write {{{ foreign import ccall "myheader.h myfunction" function :: IO ... }}} Is GHC supposed to check the existence of the header file, or do anything with it? Because I can still write {{{"myheaderBLA.h myfunction"}}} and it doesn't care about the first word (no error, ever, not even in linking, executable builds all fine). ---- Relatedly, I can write {{{ foreign import ccall "some.rubbish" f :: IO ... }}} and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain. carter suggested that maybe names with a dot inside are ignored by a linker. This leads me to the question: In my example above, is {{{myheaderBLA.h}}} actually understood as some kind of file and ignored by e.g. GHC, or is it a garbled symbol name? In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest this if the {{{"string.h"}}} part is ignored? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically
by GHC 19 Dec '14

19 Dec '14

#9845: GHC API evaluating some Cabal code fails with SegFault if executable is compiled statically -------------------------------------+------------------------------------- Reporter: | Owner: JeanPhilippeMoresmau | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: GHC API | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: 9480, 8935, 8376 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is code from the dynamic-cabal project, but I've distilled it into an easier test case. Basically you load a module that calls the Cabal configure function, and we try to call a function and get the result. This works fine if the executable is compiled with -dynamic, but segfaults (on Ubuntu at least) if the executable is static. I've had that behavior since 7.8.1 and I've seen several similar bugs come and be fixed, but the issue is still present in 7.8.4 rc1 (ghc-7.8.3.20141119) I attach the full project, with the cabal file, the Main.hs module that loads the DynamicCabalQuery.hs module -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9845> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints
by GHC 19 Dec '14

19 Dec '14

#9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The following code fails to compile under GHC 7.8.3: {{{ {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module SingletonsBug where import Control.Applicative import Data.Constraint (Dict(..)) import Data.Singletons import Data.Singletons.TH (singletons) import Data.Traversable (for) $(singletons [d| data SubscriptionChannel = BookingsChannel |]) type family T (c :: SubscriptionChannel) :: * type instance T 'BookingsChannel = Bool witnessC :: SSubscriptionChannel channel -> Dict (Show (T channel), SingI channel) witnessC SBookingsChannel = Dict forAllSubscriptionChannels :: forall m r. (Applicative m) => (forall channel. (SingI channel, Show (T channel)) => SSubscriptionChannel channel -> m r) -> m r forAllSubscriptionChannels f = withSomeSing BookingsChannel $ \(sChannel) -> case witnessC sChannel of Dict -> f sChannel }}} {{{ SingletonsBug.hs:38:15: Could not deduce (SingI channel0) arising from a use of ‘f’ from the context (Applicative m) bound by the type signature for forAllSubscriptionChannels :: Applicative m => (forall (channel :: SubscriptionChannel). (SingI channel, Show (T channel)) => SSubscriptionChannel channel -> m r) -> m r at SingletonsBug.hs:(32,6)-(34,8) or from ((Show (T a), SingI a)) bound by a pattern with constructor Dict :: forall (a :: Constraint). (a) => Dict a, in a case alternative at SingletonsBug.hs:38:7-10 The type variable ‘channel0’ is ambiguous Note: there is a potential instance available: instance SingI 'BookingsChannel -- Defined at SingletonsBug.hs:19:3 In the expression: f sChannel In a case alternative: Dict -> f sChannel In the expression: case witnessC sChannel of { Dict -> f sChannel } SingletonsBug.hs:38:17: Couldn't match type ‘channel0’ with ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: Sing a -> m r at SingletonsBug.hs:(36,3)-(38,24) Expected type: SSubscriptionChannel channel0 Actual type: Sing a Relevant bindings include sChannel :: Sing a (bound at SingletonsBug.hs:36:36) In the first argument of ‘f’, namely ‘sChannel’ In the expression: f sChannel }}} However, this works fine in GHC 7.8.2. If I change one line to this: {{{ withSomeSing BookingsChannel $ \(sChannel :: SSubscriptionChannel c) -> }}} The code compiles in GHC 7.8.3. Another change that doesn't require a type signature (but changes the program) is to change that constraint from: {{{ Show (T channel), SingI channel }}} to just {{{ SingI channel }}} It seems that the use of the type family breaks the inference, but this might be a bit of a red herring! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9575: -XAutoDeriveTypeable fails to generate instances
by GHC 19 Dec '14

19 Dec '14

#9575: -XAutoDeriveTypeable fails to generate instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | 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: -------------------------------------+------------------------------------- The following doesn't compile with GHC 7.8.3, but works with GHC HEAD. I couldn't find a matching ticket, so I don't know if this was fixed knowingly or not... {{{#!hs {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable (Typeable) data T1 = C1 Int deriving (Eq,Ord) tvoid :: Typeable a => a -> IO () tvoid _ = return () main :: IO () main = tvoid (C1 0) }}} ...fails for GHC 7.8.3 with {{{ No instance for (Typeable T1) arising from a use of ‘tvoid’ In the expression: tvoid (C1 0) In an equation for ‘main’: main = tvoid (C1 0) }}} I'm marking this with high priority, as it makes `-XAutoDeriveTypeable` unusable on GHC 7.8.3 as it stands. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9575> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles
by GHC 19 Dec '14

19 Dec '14

#8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------------+------------------------------- Reporter: haasn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- When trying to build acme-schoenfinkel (as an example), I came across an error like this: {{{ Control/Category/Schoenfinkel.hs:66:48: Could not coerce from ‘cat (cat b c, b) c’ to ‘cat (WrappedSchoenfinkel cat b c, b) c’ because ‘cat (cat b c, b) c’ and ‘cat (WrappedSchoenfinkel cat b c, b) c’ are different types. arising from the coercion of the method ‘app’ from type ‘forall b c. cat (cat b c, b) c’ to type ‘forall b c. WrappedSchoenfinkel cat (WrappedSchoenfinkel cat b c, b) c’ Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (ArrowApply (WrappedSchoenfinkel cat)) }}} It was not immediately clear to me as a user that this was caused due to it wanting GNT which was now being blocked by type roles (rightfully so, as this instance allows UnsafeCoerce!), and beyond that, what the specific rule that triggered this was. In this case the failure is due to ‘WrappedSchoenfinkel cat b c’ not being nominally equal to ‘cat b c’, in the type ‘(WrappedSchoenfinkel cat b c, b)’, which is required to be nominally equal to ‘(cat b c, b)’ because it's used as a parameter to the variable ‘cat’. Printing a location breakdown and context information similar to this to the user would help understanding and debugging roles a lot. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8749: Pattern synonyms crash GHCi
by GHC 18 Dec '14

18 Dec '14

#8749: Pattern synonyms crash GHCi ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- {{{ ghci -XPatternSynonyms > let pattern P x = x }}} causes a panic. I understand pattern synonyms are currently unsupported in GHCi, but we should give an error message, not a panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6