August 2016 - ghc-tickets

[GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer
by GHC 25 Feb '17

25 Feb '17

#12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've just taken over an existing haskell package and in the process of getting it to work with ghc 8.0 discovered that when compiling one file ghc tires to use all my ram. It basically ends up using 40% of 16 Gig before being killed by the OOM (out-of-memory) killer. The project is at: https://github.com/erikd/conduit-find.git The problem can be reproduced by: {{{ git clone https://github.com/erikd/conduit-find.git cd conduit-find git checkout test/ghc-8.0 cabal sandbox init cabal install --dependencies-only cabal build }}} which on two of my machines fails building the `Data.Cond` module. This is regression, because this code compiles fine with ghc-7.10.3 and ghc-7.8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12413: Compact regions support needs some discussion in the release notes
by GHC 23 Feb '17

23 Feb '17

#12413: Compact regions support needs some discussion in the release notes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Documentation | 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: -------------------------------------+------------------------------------- And perhaps elsewhere in the users guide. It was merged as cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10343: Make Typeable track kind information better
by GHC 22 Feb '17

22 Feb '17

#10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: 9858 Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- With all the apparent exploitable bugs now fixed, #9858 seems to be settling down. Simon P.J. asked me to make a new ticket for some quibbles I still have with limitations of the new design. These started with some examples that I discussed there pre-implementation with Richard Eisenberg, and which he concluded could be supported by a "sufficently smart solver". In the new (current) design, a `TypeRep` ''does'' contain kind information, which as I understand it is a list of `KindRep`s for the explicit kind parameters applied to the type constructor after type inference. This is sufficient to prevent confusing the same type constructor used at different kinds, and also easily supports type application ''provided'' the `TypeRep`s of the parts are known. For this, the internal `Typeable` constraint solver only ever needs to combine `TypeRep`s, never decompose them. Since no one else complained in #9858, I assume this is enough for what people are currently using `Typeable` for. However: I think the current `TypeRep` representation for `Typeable (a :: k)` doesn't contain enough information to generally extract the `KindRep` for `k` itself, much less to decompose it, even if the internal `Typeable` solver were to try. This prevents some polykinded code that is intuitively sound, and which "worked" in the old system, although if only because it didn't try to track kinds at all. For example, the following expression, with `PolyKinds` enabled: {{{#!hs typeOf :: Typeable a => Proxy a -> TypeRep }}} In the old system, this worked simply by combining the `TypeRep` for `Proxy` with the `TypeRep` for `a`. But in the new system, it fails, because the `TypeRep` for `Proxy` needs to know the kind of `a`, which is neither statically known nor available from the `TypeRep` of `a`. You would need to have compile-time information about the type constructor of `a` to even know how to build the `KindRep` from the kind arguments. This problem with constructing `TypeRep`s would arise whenever a polykinded type constructor is applied to a type whose kind is not a known monomorphic one. The second similar one I can think of is {{{#!hs typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep }}} In an ideal system, we can also find use cases that require not just extracting the `KindRep` for a type, but also decomposing it. Here is my very hypothetical kitchen sink example from [comment:46:ticket:9858] (this example was made up as a test case before I knew what the new solver would support): {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable newtype C a b = C () step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) step Proxy = Proxy nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep nest 0 x = typeRep x nest n x = nest (n-1) (step x) main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) }}} Here, to make this compile, the solver would need to derive `Typeable (C a :: [k -> *] -> *]` from `Typeable (a :: [k] -> *)`, which at runtime requires first extracting the `KindRep` of `k` from the `TypeRep` of `a`, and then building the `TypeRep` for the correctly kinded `C`. At least the former part seems essentially impossible with the current `TypeRep` representation, even with a more clever solver. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #11526: unsafeLookupStaticPtr should not live in IO
by GHC 21 Feb '17

21 Feb '17

#11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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.StaticPtr` provides {{{#!hs unsafeLookupStaticPtr :: StaticKey -> IO (Maybe (StaticPtr a)) }}} I don't think this function should live in IO. It is morally pure (the SPT that it needs to access is static for the duration of the program after all) and when this lives in IO this function cannot be used in `Binary` instances (without using `unsafePerformIO`, obviously). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11817: Add proper support for weak symbols to the runtime linker
by GHC 21 Feb '17

21 Feb '17

#11817: Add proper support for weak symbols to the runtime linker -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11223 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently weak symbols support is only partially supported by the runtime linker. The current support is mostly there to provide `COMDAT` support. In #11223 this support has been extended but there is still some work needed to finish weak symbols support. Also there needs some investigation into how this support should look like. E.g. are we only supporting linking weak symbols in C or do we want to support it in Haskell as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures
by GHC 21 Feb '17

21 Feb '17

#11011: Type-indexed TypeReps, Static Pointers and Distributed Closures -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- There is a mock-up of a new API for type indexed type representations, basic Dynamic functionality, static pointers and distributed closures (https://github.com/brprice/typeableT) based on https://ghc.haskell.org/trac/ghc/wiki/TypeableT. We would like to invite comments and discussion from the community using this ticket as a more permenant home that email. One particular point that would benefit from more eyes is the polymorphic static pointers support. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11011> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #12428: Allow pattern synonyms to optionally carry coerceability
by GHC 20 Feb '17

20 Feb '17

#12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Aside from their more interesting abilities, pattern synonyms can be used for name management. For example, if a module exports a type with a data constructor named `A`, and also re-exports a type with a data constructor named `A`, it can use a pattern synonym to rename the imported constructor. If the type is a `newtype`, this pattern synonym will not carry coerceability. Sometimes, this is exactly what one would desire (an "unsafe" module breaking through a newtype abstraction may wish to allow importers to confine coerceability). Other times, it's not (pattern synonym just for name control). When defining a pattern synonym for a type in a module in which that type is coerceable, it would be nice to be able to tell GHC that the pattern synonym should carry coerceability. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied
by GHC 20 Feb '17

20 Feb '17

#11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Type checker) | 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: -------------------------------------+------------------------------------- in an effort to simulate the TypeError close type family in userland, I was doing a bit of experimentation with type families in ghc 7.10 and 8.0 RC2, and i was surprised to find that i can't get fully applied closed type families to reduce "strictly" when they are fully applied to concrete arguments within a Constraint Tuple. Roughly, I want to be able to write "Assert x" style predicates in a type signature, and have those be checked/ reduced at the definition site rather than the use site. It seems like what I would have to do is do a slight indirection the form {{{ publicFunName :: SimpleType c1 c2 --- c1 c2 are two concrete types publicFunName ... = guardedFun where guardedFun :: (MyClosedTypeFamAssert c1 c2)=> SimpleType c1 c2 guardedFun ... = ... -- myClosedTypeFamAssert (x :: *) (y :: *) :: Constraint }}} I guess this SORTOF makes sense that it doesn't get reduced strictly at the definition site (though its a sort of normalization i feel like). I think the sibling computation where i have `myClosedTypeFamAssert (x :: *) (y :: *) :: Bool` and have the guard be ('True ~ myClosedTypeFamAssert c1 c2 ), but I was hoping i could have things look a teeny bit more "Assertion" style for aesthetical reasons enclosed below is a self contained module that exhibits a more worked out example {{{ {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies, TypeOperators #-} {-# LANGUAGE DataKinds, GADTs #-} {-# LANGUAGE TypeInType, ConstraintKinds #-} module Main where import GHC.Types (Constraint,TYPE,Levity(..)) main = print (7 :: Int)-- this works -- main = print (sevenBad :: Int ) -- this does error, but its at the use site rather than definition site! -- using this one ""works"", but results in a VERY confusing type error involving -- type family WorstClosedStuckError (x :: a) :: Constraint where WorstClosedStuckError a = (False ~ True) --- empty closed type families are ONLY allowed as of ghc 8.0 type family ClosedStuckSilly (x :: a) :: b where type family ClosedStuckSillyConstr (x :: a) :: Constraint where --- this is analogous to a version of the TypeError family in GHC.TypeLits in 8.0 onwards --- but kind polymorphic closed empty type families dont seem to trigger a type error in the definition site --- but rather in the USE site type family ClosedStuckTypeConstr (x :: TYPE Lifted) :: Constraint where type family ClosedStuckType (x :: TYPE Lifted) :: b where --- these two seem to work OK -- these two only only report an error once I resolve the constraint on a to something like Int etc sevenBad :: (ClosedStuckSilly 'True , Num a) => a sevenBad = 7 sevenOtherBad :: (ClosedStuckSillyConstr 'False, Num a) => a sevenOtherBad = 7 -- this one fails to type check at the definition site, but has a SUPER confusing -- error about allow ambiguous types sevenBadWorst :: (WorstClosedStuckError 'False, Num a) => a sevenBadWorst = 7 sevenOKButNotUseful :: (ClosedStuckType Bool, Num a) => a sevenOKButNotUseful = 7 -- i have to do an indirection to force an "assertion" / "reduction", the following triggers the error as expected sevenIndirect :: Num a => a sevenIndirect = sevenBad }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12409: Unboxed tuples have no type representations
by GHC 18 Feb '17

18 Feb '17

#12409: Unboxed tuples have no type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket continues with the long tradition of types missing type representations (see #12082, #12132, #11120). This time the culprit is unboxed tuples, {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import Data.Typeable λ> :set -XUnboxedTuples λ> typeRep (Proxy :: Proxy (#Int, Int#)) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tyConRep (#,#) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem, as usual, is that the tycons are missing from `knownKeyNames`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12243: RebindableSyntax and OverloadedLabels
by GHC 17 Feb '17

17 Feb '17

#12243: RebindableSyntax and OverloadedLabels -------------------------------------+------------------------------------- Reporter: htebalaka | 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: -------------------------------------+------------------------------------- Should these extensions work together? I wasn't able to come up with a good motivating example; I was playing around with lenses, and thought a more restrictive class definition might aid type inference, though it turned out in that particular case it didn't. In the general case I think it might still be useful. I didn't see any discussion on this, and it seemed like maybe it's an oversight. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4