April 2018 - ghc-tickets

[GHC] #9692: Template Haskell reification for Data Families is buggy?
by GHC 08 Nov '18

08 Nov '18

#9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: TemplateHaskell | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have found an example where I think that the TH reification for data/newtype families is incorrect, in that if forgets non-instantiated type variables in instance declarations. For the attached example, it will infer the Info: {{{#!hs FamilyI (FamilyD DataFam TyFamReifyDefs.F [PlainTV a_1627399879,PlainTV b_1627399880] (Just StarT)) [DataInstD [] TyFamReifyDefs.F [ConT GHC.Types.Int] [NormalC TyFamReifyDefs.FInt [(NotStrict,VarT x_1627399881)]] []] }}} Note how the variable x is not declared in the body of the DataInstD. Since it does not need to have the same name as the family-declared variable, substituing is non-trivial this way... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly
by GHC 08 Nov '18

08 Nov '18

#14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This can be observed on GHC 8.0.1 or later: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where data family Fam a data instance Fam Int data instance Fam Int }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:5:15: error: Conflicting family instance declarations: Fam Int = -- Defined at Bug.hs:5:15 Fam Int = -- Defined at Bug.hs:6:15 | 5 | data instance Fam Int | ^^^ }}} Notice how GHC attempts to pretty-print the RHS by using a `=` symbol, but there is no RHS! This gets even more confusing with this program, which requires GHC HEAD: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where data family Fam :: k -> * data instance Fam :: * -> * data instance Fam :: * -> * }}} {{{ $ ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170818: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:15: error: Conflicting family instance declarations: Fam = -- Defined at Bug.hs:6:15 Fam = -- Defined at Bug.hs:7:15 | 6 | data instance Fam :: * -> * | ^^^ }}} Not only is there no RHS, but the kind signatures of each instance aren't printed either. This is an issue, since the entire reason why the two instances conflict are because of their kinds! We should rethink how data family instances are pretty printer here to avoid this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b)
by GHC 08 Nov '18

08 Nov '18

#11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.8.3 (other) | Keywords: array | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Array` has `Eq`, `Ord`, `Show` and `Read` instances but `UArray` only has `Eq`, `Ord` and `Show`. Add the missing `Read` instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13933: Support Typeable instances for types with coercions
by GHC 07 Nov '18

07 Nov '18

#13933: Support Typeable instances for types with coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: TypeInType, | Operating System: Unknown/Multiple Typeable | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs {-# LANGUAGE GADTs, TypeApplications, TypeInType #-} module Bug where import Type.Reflection data G a where MkG :: a ~ Bool => G a rep = typeRep @MkG }}} I get {{{ Bug.hs:10:7: error: • No instance for (Typeable <>) arising from a use of ‘typeRep’ • In the expression: typeRep @MkG In an equation for ‘rep’: rep = typeRep @MkG | 10 | rep = typeRep @MkG | }}} First off, the error message is confusing, mentioning the mysterious `<>`. But more importantly, it would be nice if the `Typeable` mechanism supported coercions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11008: GND with Type Families
by GHC 07 Nov '18

07 Nov '18

#11008: GND with Type Families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 the following code: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances #-} class C r type family F r newtype Foo r = Foo r instance (C (F r), Eq r) => Eq (Foo r) newtype Bar r = Bar (Foo r) deriving (Eq) }}} GHC produces the error {{{ No instance for (C (F r)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq (Bar r)) }}} If I enable `StandaloneDeriving`, I am able to derive the instance: `deriving instance (Eq (Foo r)) => Eq (Bar r)` [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.ht… #newtype-deriving The docs] indicate that this is exactly the instance that should be generated by GND for `newtype T v1..vn = MkT (t vk+1..vn) deriving (C t1..tj)`, where my code uses the following parameters: {{{ T = Bar v1 = r n = 1 MkT = Bar t = Foo r k= 1 C = Eq j = 0 }}} and all of the conditions enumerated in the docs seem to be met. Furthermore, `Bar` seems to fit squarely into the format of `data T1` in section 7.5.1 of the same documentation, which indicates it should not need `StandaloneDeriving`. It seems that the type family constraint on the `Eq` instance for `Foo` is causing the problem, but it's not clear why I'm forced to write a standalone instance that is identical to the one that should be generated by GND. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12620: Allow the user to prevent floating and CSE
by GHC 07 Nov '18

07 Nov '18

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- This is a write-up of a rough idea that Andres Löw and me had at ICFP 2016 in order to address some Real World problems Andres noticed and that are currently hard to avoid. The goal is to give the user more control about expressions that the compiler would like to float out (or CSE), but the programmer knows better. Example (assume no list fusion exists): {{{ enum xs = zip [1..] xs }}} This leads to a horrible space leak, as GHC will float out `[1..]` to the top. Our idea is to have a magic function `nofloat :: a -> a` (magic in the same sense as `inline` and `lazy`) that the programmer would use here: {{{ enum xs = zip (nofloat [1..]) xs }}} With these effects: * Sub expressions are not floated out of a `nofloat`. * An expression of the form `nofloat e` would not be floated beyond the innermost enclosing lambda. * Two expressions of the form `nofloat e` would not be commoned up by CSE. This way, unwanted sharing is prevented. In contrast to a hypothetical `veryCheap` function, it does ''not'' mean that the compiler should float it into lambda (no unwanted duplication either). Two open questions (among many others, I am sure:) * Likely, rule matching should look through `nofloat`. At least in this example (and similar ones like `map (nofloat [1..])`, the rules in question will avoid the spaceleaks). * Possibly, nothing should be floated (inlined) ''into'' a `nofloat`. Rationale: Assume the library is changed so that {{{ [n..] = nofloat (realEnumFrom n) {-# INLINE [n..] #-} }}} Then `zip [fib 1000..]` would be rewritten by the inliner to `zip (let x = fib 1000 in (nofloat [x..]))`. Moving the `fib 1000` into the `nofloat` would change the behaviour in a possibly surprising way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12620> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #13080: Constant values are not floated out of the loop
by GHC 07 Nov '18

07 Nov '18

#13080: Constant values are not floated out of the loop -------------------------------------+------------------------------------- Reporter: Feuerbach | 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: -------------------------------------+------------------------------------- See this stackoverflow post: http://stackoverflow.com/a/41521876/110081 Basically, the following program leaks memory on ghc 7.10.3 and ghc 8.0.1. {{{#!hs import Control.Monad (forever) main :: IO () main = worker {-# NOINLINE worker #-} worker :: (Monad m) => m () worker = forever $ poll () poll :: (Monad m) => () -> m a poll action = do return () poll action }}} Could ghc do better there? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #15009: Float equalities past local equalities
by GHC 05 Nov '18

05 Nov '18

#15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Consider the two datatypes {{{#!hs data T1 a where MkT1 :: a ~ b => b -> T1 a data T2 a where MkT2 :: a -> T2 a }}} To me, these look like two ways of writing the same thing. Yet they participate quite differently in type inference. If I say {{{#!hs f (MkT1 a) = not a g (MkT2 a) = not a }}} then `g` is accepted (with type `T2 Bool -> Bool`) while `f` is rejected as GHC mutters about untouchable type variables. Of course, GHC's notion of untouchable type variables is a Good Thing, with arguments I won't rehearse here. It all boils down to this rule: (*) Information that arises in the context of an equality constraint cannot force unification of a unification variable born outside that context. I think this rule is a bit too strict, though. I propose a new rule: (%) Information that arises in the context of a ''non-purely-local'' equality constraint cannot force unification of a unification variable born outside that context. where '''Definition:''' An equality constraint is ''purely local'' if every type variable free in the constraint has the same scope as the constraint itself. That is, if an equality constraint mentions only variables freshly brought into scope -- and no others -- then we can still unify outer unification variables. Happy consequences of this choice: * `f` above could be accepted, as the equality in `MkT1` is purely local. * Rule (%) allows users to effectively let-bind type variables, like this: {{{#!hs f :: forall a. (a ~ SOME REALLY LONG TYPE) => Maybe a -> Maybe a -> Either a a }}} Currently, this kind of definition (if it's, say, within a `where` clause) triggers rule (*) in the body of the function, and thus causes type inference to produce a different result than just inlining `SOME REALLY LONG TYPE`. * We could theoretically simplify our treatment of GADTs. Right now, if you say {{{#!hs data G a b c where MkG :: MkG d Int [e] }}} GHC has to cleverly figure out that `d` is a universal variable and that `e` is an existential, producing the following Core: {{{#!hs data G a b c where MkG :: forall d b c. forall e. (b ~ Int, c ~ [e]) => MkG d b c }}} If we use rule (%), then I believe the following Core would behave identically: {{{#!hs data G a b c where MkG :: forall a b c. forall d e. (a ~ d, b ~ Int, c ~ [e]). MkG a b c }}} This treatment is more uniform and easier to implement. (Note that the equality constraints themselves are unboxed, so there's no change in runtime performance.) What are the downsides of (%)? I don't think there are any, save an easy extra line or two in GHC to check for locality. Rule (*) exists because, without it, GHC can infer non-principal types. However, I conjecture that Rule (%) also serves to require inference of only principal types, while being more permissive than Rule (*). I'm curious for your thoughts on this proposal. (I am making it here, as this is really an implementation concern, with no discernible effect on, say, the user manual, although it would allow GHC to accept more programs.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13904: LLVM does not need to trash callee-saved registers.
by GHC 03 Nov '18

03 Nov '18

#13904: LLVM does not need to trash callee-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: llvm, codegen | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #4992 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **Summary**: This ticket is a simplification of the LLVM backend that I already plan to do in another branch, but I'd like to push the patch into `master`, and then merge from `master` into that branch. The LLVM backend attempts to trash the physical registers corresponding to Rx, Fx, and Dx registers that are caller-saved before an FFI call by emitting a sequence such as this: {{{#!llvm store i64 undef, i64* %R3_Var store i64 undef, i64* %R4_Var store i64 undef, i64* %R5_Var store i64 undef, i64* %R6_Var store float undef, float* %F1_Var store double undef, double* %D1_Var store float undef, float* %F2_Var store double undef, double* %D2_Var store float undef, float* %F3_Var store double undef, double* %D3_Var store float undef, float* %F4_Var store double undef, double* %D4_Var store float undef, float* %F5_Var store double undef, double* %D5_Var store float undef, float* %F6_Var store double undef, double* %D6_Var %ln7bu = call ccc double (double) @llvm.sin.f64( double %ln7bs ) nounwind }}} Where the Rx/Fx/Dx registers are chosen based on what physical register those global registers map to, and whether those physical registers are caller-saved according to the C ABI. I'm certain this is unnecessary, as there is no way to know the physical register corresponding to those vars within an LLVM IR function. The calling convention used for the FFI call will preserve caller-saved registers as needed, i.e., only if such a value is needed after the call. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness
by GHC 02 Nov '18

02 Nov '18

#14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #7210 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data A = A { a :: {-# UNPACK #-} Maybe Int} }}} {{{ [1 of 1] Compiling Main ( Temp.hs, Temp.o ) Temp.hs:1:19: error: • Unexpected strictness annotation: {-# UNPACK #-}Maybe • In the type ‘{-# UNPACK #-}Maybe Int’ In the definition of data constructor ‘A’ In the data declaration for ‘A’ | 1 | data A = A { a :: {-# UNPACK #-} Maybe Int} | }}} The diagnostic is incorrect because it complains about an "unexpected strictness annotation" although the error is the opposite. A quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14