December 2016 - ghc-tickets

[GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix
by GHC 09 Jan '17

09 Jan '17

#13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC loops when compiling this code. Replacing the _ with the actual type fixes the error. {{{#!hs {-# LANGUAGE PolyKinds, DataKinds, TypeOperators, TypeFamilies, TemplateHaskell, GADTs, PartialTypeSignatures #-} import Data.Vinyl import Data.Singletons.TH newtype MyAttr a b = MyAttr { _unMyAttr :: MyFun (a b) } type MyRec a b = Rec (MyAttr a) b type family MyFun (a :: k1) :: k2 data GY (a :: k1) (b :: k2) (c :: k1 -> k3) (d :: k1) data GNone (a :: k1) type family GYTF a where GYTF (GY a b _ a) = b GYTF (GY _ _ c d) = MyFun (c d) type instance MyFun (GY a b c d) = GYTF (GY a b c d) type family GNoneTF (a :: k1) :: k2 where type instance MyFun (GNone a) = GNoneTF a type (a :: k1) =: (b :: k2) = a `GY` b type (a :: j1 -> j2) $ (b :: j1) = a b infixr 0 $ infixr 9 =: data FConst (a :: *) (b :: Fields) data FApply (a :: * -> * -> *) b c (d :: Fields) data FMap (a :: * -> *) b (d :: Fields) type instance MyFun (FConst a b) = a type instance MyFun (FApply b c d a) = b (MyFun (c a)) (MyFun (d a)) type instance MyFun (FMap b c a) = b (MyFun (c a)) data Fields = Name | Author | Image | Description | Ingredients | Instructions | CookTime | PrepTime | TotalTime | Yield | Nutrition | Tags | Url | Section | Items | Subsections | Calories | Carbohydrates | Cholesterol | Fat | Fiber | Protien | SaturatedFat | Sodium | Sugar | TransFat | UnsaturatedFat | ServingSize genSingletons [ ''Fields ] (=::) :: sing f -> MyFun (a f) -> MyAttr a f _ =:: x = MyAttr x type NutritionT = Calories =: Maybe Int $ Carbohydrates =: Maybe Int $ Cholesterol =: Maybe Int $ Fat =: Maybe Int $ Fiber =: Maybe Int $ Protien =: Maybe Int $ SaturatedFat =: Maybe Int $ Sodium =: Maybe Int $ Sugar =: Maybe Int $ TransFat =: Maybe Int $ UnsaturatedFat =: Maybe Int $ ServingSize =: String $ GNone type NutritionRec = MyRec NutritionT ['Calories, 'Carbohydrates, 'Cholesterol, 'Fat, 'Fiber, 'Protien, 'SaturatedFat, 'Sodium, 'Sugar, 'TransFat, 'UnsaturatedFat, 'ServingSize] type RecipeT = Name =: String $ Author =: String $ Image =: String $ Description =: String $ CookTime =: Maybe Int $ PrepTime =: Maybe Int $ TotalTime =: Maybe Int $ Yield =: String $ Nutrition =: NutritionRec $ Tags =: [String] $ Url =: String $ GNone type RecipeFormatter = FApply (->) (FConst [String]) (FMap IO RecipeT) g :: MyRec RecipeFormatter _ --'[ 'Author ] Uncomment to prevent loop g = SAuthor =:: (\a -> return "Hi") :& RNil main = putStrLn "Hi" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13050: Holes don't work infix
by GHC 08 Jan '17

08 Jan '17

#13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As pointed out in this [https://twitter.com/deech/status/815294260115369985 tweet], holes don't work infix {{{ #Haskell holes don't work with infixed functions, eg. _ 1 1 (Hole found: Integer -> Integer -> ...) 1 `_` 1 (parse error) 1 `_x` 1 (same) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13050> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy
by GHC 07 Jan '17

07 Jan '17

#12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The reason why this module isn't inferred safe is that it uses `unsafePerformIO` to create a global `IORef`. From a SafeHaskell perspective, this module isn't very useful in itself, but its unsafety prevents other modules that import it to provide class instances from being inferred as safe. A concrete example is https://hackage.haskell.org/package/exceptions-0.8.3/docs/src/Control- Monad-Catch.html#line-186 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13048: Splitter is O(n^2)
by GHC 06 Jan '17

06 Jan '17

#13048: Splitter is O(n^2) -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: split-objs | 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: -------------------------------------+------------------------------------- The splitter is O(local constants * total size of code), which is O(n^2^). This can be dealt with by not looping over each local constant, and instead scraping the local constants used from the assembler code and then looking them up in the hashtable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell
by GHC 06 Jan '17

06 Jan '17

#12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12976 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noticed in #12976. First, fire up GHCi 8.0.2 (or HEAD) and enable some options: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161208: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax }}} Next, try looking at the kind of a regular unboxed tuple: {{{ λ> :k (#,#) (#,#) :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a -> TYPE b -> TYPE 'UnboxedTupleRep }}} But when you splice in the unboxed tuple type constructor via Template Haskell, `:k` misbehaves: {{{ λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: * -> * -> TYPE 'UnboxedTupleRep }}} This kind is totally wrong, since you //can// in fact apply this type constructor to types with kinds other than `*`: {{{ λ> :k $(unboxedTupleT 2) Int# Int# $(unboxedTupleT 2) Int# Int# :: TYPE 'UnboxedTupleRep }}} Moreover, this appears to be a regression since GHC 8.0.1, since if you try this in GHCi 8.0.1: {{{ $ /opt/ghc/8.0.1/bin/ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a -> TYPE b -> TYPE 'UnboxedTupleRep }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12985> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12896: Consider using compact regions in GHC itself to reduce GC overhead
by GHC 06 Jan '17

06 Jan '17

#12896: Consider using compact regions in GHC itself to reduce GC overhead -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- In make mode, GHC keeps a lot of in-memory data structures about modules it has built and interface files it has read. These data structures are long-lived and immutable (at least, per module/mutually recursive module group/package), so they may be candidates for storing in compact regions to reduce the work done by the GC. Potential problem: if we rely heavily on lazy evaluation in these structures for the purpose of avoiding work that will never be needed, then we can't store them in a compact region (since the contents of a compact region must be fully evaluated). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9748: Disambiguate IO actions in GHCi with :set +t
by GHC 06 Jan '17

06 Jan '17

#9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently GHCi's `:set +t` displays the same type for the following: {{{#!hs % ghci -ignore-dot-ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char Prelude> return 'a' :: IO Char 'a' it :: Char }}} A user at `#haskell-beginners` ran into a problem where they mistook an expression that defaulted to IO for a pure expression (`Id . even <$> pure 5`), `:set +t` was suggested but ended up showing the incorrect type: {{{#!hs ghci> Id . even <$> pure 5 Id False it :: Id Bool }}} This is bad for pedagogical reasons, it would be an improvement to display the following: {{{#!hs Prelude> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char <- return 'a' :: IO Char Prelude> return 'a' :: IO Char 'a' it :: Char <- return 'a' :: IO Char }}} mirroring existing syntax: {{{#!hs Prelude> :set -XScopedTypeVariables Prelude> a :: Char <- return 'a' :: IO Char a :: Char }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1)
by GHC 06 Jan '17

06 Jan '17

#13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was recently made aware that [http://hackage.haskell.org/package/vinyl vinyl]'s performance dramatically deteriorated with GHC 8.0.1 when compared to GHC 7.x. Vinyl is an extensible records library that's been around for about four years; the aspect of its design relevant here is the basic HList-style indexed GADT. Care was taken in the past so that working with, say, a `Storable` `Vector` of records would suffer no overhead from `vinyl` when compared with standard records, and we have a benchmark suite to spot check this. In the move to GHC-8.0.1, it turns out that we do introduce overhead. Inspecting the Core reveals that the benchmark inner loop includes a `case` match on an `HEq_sc` value whose presence I would not expect, and that is not present when compiling with GHC-7.10.3: {{{ case HEq_sc @ Nat @ Nat @ ('S 'Z) @ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)]) ($s$fRElemar:S_$s$fRElemar:S_$cp1RElem `cast` (N:~[0] <Nat>_N <'S 'Z>_N <RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)]>_N :: (('S 'Z :: Nat) ~ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)] :: Nat) :: Constraint) ~R# (('S 'Z :: Nat) ~~ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)] :: Nat) :: Constraint))) of cobox0 { __DEFAULT -> }}} I have since made an effort to reproduce the issue, and discovered more fragility than I expected. I am attaching two modules: `Rec.hs` defines a kind of record type, `Main.hs` is a test program that I will reproduce here, {{{ {-# LANGUAGE DataKinds #-} module Main where import Rec type MyRec = Rec '[ '("A",Int), '("B",Int), '("C",Int) ] getC :: MyRec -> Int getC = getField (Proxy::Proxy '("C",Int)) doubleC :: MyRec -> MyRec doubleC r = setC (2 * (getC r)) r where setC = set . (Field :: Int -> Field '("C",Int)) main :: IO () main = print (getC (Field 1 :& Field 2 :& Field 3 :& Nil :: MyRec)) }}} If the `doubleC` definition is present, the Core emitted (with `-O2`) includes an `HEq_sc` case in the RHS of `getC`. If `doubleC` is commented out, that `case HEq_sc ...` is no longer present. In this example, the offending piece of Core is, {{{ case HEq_sc @ Nat @ Nat @ (Index '("C", Int) '['("B", Int), '("C", Int)]) @ ('S 'Z) ($s$fHasFieldkr:S_$s$fHasFieldkr:S_$cp1HasField `cast` (N:~[0] <Nat>_N <Index '("C", Int) '['("B", Int), '("C", Int)]>_N <'S 'Z>_N :: ((Index '("C", Int) '['("B", Int), '("C", Int)] :: Nat) ~ ('S 'Z :: Nat) :: Constraint) ~R# ((Index '("C", Int) '['("B", Int), '("C", Int)] :: Nat) ~~ ('S 'Z :: Nat) :: Constraint))) of cobox1 { __DEFAULT -> }}} If the contents of `Rec.hs` are included in `Main.hs`, the `case HEq_sc ...` is not present in the resulting Core. The result of what looks like a failure to normalize the `Index` type family (or `RIndex` in `vinyl`) manifests as a 2x slowdown in the benchmark available in the `vinyl` repository. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10352: Properly link Haskell shared libs on ELF systems
by GHC 05 Jan '17

05 Jan '17

#10352: Properly link Haskell shared libs on ELF systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Package | Version: 7.11 system | Operating System: Linux Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since the early days of building Haskell shared libs on Linux we have been using a scheme that is really a bit of a hack. We should do it properly. In my blog post on this from 2009 (http://www.well-typed.com/blog/30/) I said: > If we use ldd again to look at the libfoo.so that we've made we will notice that it is missing a dependency on the rts library. This is problem that we've yet to sort out, so for the moment we can just add the dependency ourselves: > > $ ghc --make -dynamic -shared -fPIC Foo.hs -o libfoo.so \ > -lHSrts-ghc6.11 -optl-Wl,-rpath,/opt/ghc/lib/ghc-6.11/ > > The reason it's not linked in yet is because we need to be able to switch which version of the rts we're using without having to relink every library. For example we want to be able to switch between the debug, threaded and normal rts versions. It's quite possible to do this and it just needs a bit more rearranging in the build system to sort it out. Once it's done you'll even be able to switch rts at runtime, eg: > > $ LD_PRELOAD=/opt/ghc/lib/ghc-6.11/libHSrts_debug-ghc6.11.so > $ ./Hello So in general, if a shared lib requires symbols from another shared lib then it should depend on it. In ELF terminology that means a NEEDED entry to say this lib needs that other lib. This is important to be able to link and load these shared libraries, otherwise they can have dangling dependencies. But we don't do this. For the specific case of the RTS we do not link Haskell shared libs against the RTS. So they have lots of dangling symbols. These libraries cannot be loaded on their own, e.g. with `dlopen()`. This is bad, and has other knock-on consequences. Why don't we link to the RTS? It's because historically (with static linking) GHC had had the ability to select the flavour of the RTS when final executables are linked, not when intermediate libraries are created. This works because the RTS flavours share a common ABI. This is a useful feature as it lets us select the SMP or debug or other RTS at final link time. So when we made up the first shared lib scheme on ELF we had to support this. Our initial scheme was like this: don't link Haskell library DSOs against the RTS, only like the final exe against the RTS. Each RTS flavour has a separate SONAME, e.g. `libHSrts_thr-ghc7.8.4.so` or `libHSrts_debug- ghc7.8.4.so`. This works because the runtime linker looks at the final exe first and loads the RTS, and then when other libs are loaded the symbols all resolve. Why can't we link all the libraries against the RTS? Currently each RTS flavour has a different SONAME, which is the key that the dynamic linker uses to identify each library. So if we did link all the Haskell libs against "the" RTS we would have to pick which one at the point at which we create the library, and that'd stop us from being able to choose later. So, can we use a better scheme? We want one that doesn't leave dangling undefined references in intermediate Haskell libs, and is also compatible with the ability to select the flavour of the RTS at final exe link time (or even override it at load time). Yes we can! The first thing to note is that to be interchangeable, all the RTS flavours (that share a compatible ABI) need to have the same SONAME. So for example, all the (non-profiling) RTS DSO files have to have the internal SONAME of `libHSrts-ghc7.8.4.so`. Once they all have the same SONAME, then it's ok for all the Haskell libs to specify a NEEDED dependency on that rts SONAME. But if they have the same SONAME, what do the files get called, where do they live and how are they found? The trick is to make use of the search path. Put each RTS flavour in a different directory, but otherwise with the same filename, e.g. `lib/rts-1.0/thr/libHSrts-ghc7.8.4.so`, `lib/rts-1.0/debug/libHSrts-ghc7.8.4.so` etc. Each library DSO and exe has its list of NEEDED entries, and it has an RPATH entry used to find those libraries if they're not loaded yet. The key is the "if they're not loaded yet" bit. Remember that the linker uses the SONAME as the key to decide if the lib is loaded yet or not. So the libraries could all have an RPATH entry to say to look for the RTS in the directory containing the default RTS flavour. But then the top level exe (or foreign/export shared lib) can also link to the RTS directly (ie an NEEDED entry) and can specify an RPATH which can be for any of the rts flavours. When the linker loads the top level exe, it will loads the selected RTS using the exe's RPATH, and then when the linker sees other Haskell libs that have a NEEDED entry on the RTS it will ignore them because the RTS's SONAME is already loaded. So concretely, instead of: lib/ghc-${ver}/rts-1.0/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_debug-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_l-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr_l-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr_debug-ghc${ver}.so each with a different SONAME we'd have lib/ghc-${ver}/rts-1.0/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/debug/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/l/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr_l/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr_debug/libHSrts-ghc${ver}.so each with the same SONAME When linking libs we would always use `-lHSrts -rpath lib/ghc-${ver}/rts-1.0` When linking exes (or shared libs for external consumption) we would use both `-lHSrts` and `-rpath lib/ghc-${ver}/${rtsflavour}/rts-1.0`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9248: Document -XHaskell98 and -XHaskell2010 in flag reference
by GHC 05 Jan '17

05 Jan '17

#9248: Document -XHaskell98 and -XHaskell2010 in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | 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: | ------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3