- ghc-tickets - Haskell.org

Re: [GHC] #7204: Use a class to control FFI marshalling
by GHC 23 Feb '17

23 Feb '17

#7204: Use a class to control FFI marshalling -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Now that #2721/#8165 have been fixed, the technical obstacle of not being able to use `GeneralizedNewtypeDeriving` on classes with associated types is gone. The only question remaining is if we want to pursue this design. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7204#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12863: Associated data families don't use superclasses when deriving instances
by GHC 23 Feb '17

23 Feb '17

#12863: Associated data families don't use superclasses when deriving instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- {{{#!hs class Functor (TotalMap key) => Key key where data TotalMap key :: Type -> Type (¡) :: TotalMap key val -> key -> val }}} a constraint `Key key` entails a `Functor (TotalMap key)` constraint, using the notation of [https://hackage.haskell.org/package/constraints constraints] {{{#!hs prf1 :: Key key :- Functor (TotalMap key) prf1 = Sub Dict prf2 :: (Key key1, Key key2) :- (Functor (TotalMap key1), Functor (TotalMap key2)) prf2 = prf1 *** prf1 }}} Yet these proofs are not used in {{{#!hs -- tzLp.hs:28:89-95: error: … -- • No instance for (Functor (TotalMap key1)) -- arising from the first field of ‘PairMap’ -- (type ‘TotalMap key1 (TotalMap key2 val)’) -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Functor (TotalMap (key1, key2))) -- Compilation failed. instance (Key key1, Key key2) => Key (key1, key2) where data TotalMap (key1, key2) val = PairMap (TotalMap key1 (TotalMap key2 val)) deriving Functor (¡) :: TotalMap (key1, key2) val -> ((key1, key2) -> val) PairMap keys ¡ (k1, k2) = keys ¡ k1 ¡ k2 }}} I would expect it to work like {{{#!hs deriving instance (Key key1, Key key2) => Functor (TotalMap (key1, key2)) }}} Same problem occurs with only a single constraint {{{#!hs -- tzLp.hs:33:14-20: error: … -- • No instance for (Functor (TotalMap key)) -- arising from the first field of ‘Id’ (type ‘TotalMap key val’) -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Functor -- (TotalMap (Identity key))) -- Compilation failed. instance Key key => Key (Identity key) where data TotalMap (Identity key) val = Id (TotalMap key val) deriving Functor }}} which should work like {{{#!hs deriving instance Key key => Functor (TotalMap (Identity key)) -- or deriving instance Functor (TotalMap key) => Functor (TotalMap (Identity key)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12863> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 23 Feb '17

23 Feb '17

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12863 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12863 Comment: See also #12863 for another occurrence of this design question. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13244: Error Dealing with Unboxed Types and Type Families
by GHC 22 Feb '17

22 Feb '17

#13244: Error Dealing with Unboxed Types and Type Families ----------------------------------------+--------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: pprIfaceCo | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hello, I was playing with unboxed types and this happened: [2 of 2] Compiling Data.Unbox ( Data/Unbox.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Data/Unbox.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): pprIfaceCo I will attach the relevant file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5302: Unused arguments in join points
by GHC 22 Feb '17

22 Feb '17

#5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Still reproducible in HEAD. * The reason the late demand-analysis doesn't catch it is because we don't do w/w. (Reason: see `Note [Final Demand Analyser run]` in `DmdAnal`.) * The absent argument is actually a case binder, passed as a result of `Note [Case binders and join points]` in `Simplify`. But in this case it turns out that not only is the case-binder argument eventually unused, but (even worse) every `juump` to that join point looks like `jump j x (I# x)`. So we box it, and then immediately discard it. Urk. Just recording breadcrumbs for now. My thought: never pass the case binder to a join point; instead re-box it. It's much the same trade-off as in other places where we worry about re-boxing. And it would be a lot simpler; in particular, we can stop having unfoldings in lambda-binders, which is pretty dodgy anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13300: panic! isInjectiveTyCon sees a TcTyCon W
by GHC 22 Feb '17

22 Feb '17

#13300: panic! isInjectiveTyCon sees a TcTyCon W -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code causes the compiler to panic {{{ #!haskell {-# LANGUAGE GADTs #-} data W where WI :: Int WD :: Double data Superblock = A { f :: W } | B { f :: W } }}} {{{ [1 of 1] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/hdf5/hdf5-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon W Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package hdf5-0.1.0.0 using: /home/siddhu/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.2.0-ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build exe:hdf5 --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13300> 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] #13163: Make type import/export API Annotation friendly
by GHC 22 Feb '17

22 Feb '17

#13163: Make type import/export API Annotation friendly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment an export of the form {{{#!hs type C(..) }}} is parsed by the rule {{{ | 'type' oqtycon {% amms (mkTypeImpExp (sLL $1 $> (unLoc $2))) [mj AnnType $1,mj AnnVal $2] } }}} This means that the origiinal `oqtycon` loses its location which is then retained in the `AnnVal` annotation. The problem is if the `oqtycon` has its own annotations, these get lost. e.g. in {{{#!hs type (?)(..) }}} the parens annotations for `(?)` get lost. This can be solved by introducing a new `IE` constructor `IEVarType`, treated exactly the same as `IEVar` in the rest of the processing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13221: OccurAnal fails to rediscover join points
by GHC 22 Feb '17

22 Feb '17

#13221: OccurAnal fails to rediscover join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not clear why the warning from `OccurAnal` about rediscovering join points is ever firing. There's one circumstance I can think of, namely the special typing rule allowing jumps from β-redexes, but the warning fires repeatedly and β-redexes don't survive the simplifier. This isn't hard evidence of something wrong, but it indicates the occurrence analyzer may be missing something. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

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

22 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