- ghc-tickets - Haskell.org

[GHC] #10797: Kind-level functional dependencies are not resolved properly
by GHC 13 Apr '17

13 Apr '17

#10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | 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 Revisions: | -------------------------------------+------------------------------------- Hello! Let's consider such funny class and its instances. {{{ {-# LANGUAGE PolyKinds #-} ... class BaseType (a :: k) (b :: l) | a -> b, k -> l where baseType :: Proxy a -> Proxy b instance BaseType (a :: j -> k) (out :: l) => BaseType (a (t :: j) :: k) (out :: l) }}} The instance does not compile: {{{ Illegal instance declaration for ‘BaseType (a t) out’ The liberal coverage condition fails in class ‘BaseType’ for functional dependency: ‘k -> l’ Reason: lhs type ‘k’ does not determine rhs type ‘l’ In the instance declaration for ‘BaseType (a (t :: j) :: k) (out :: l)’ }}} While the LHS determines the RHS. The problem is that it seems, that GHC doesn't infer the functional dependency of {{{k ~> l}}} from the dependency {{{j -> k ~> l}}}.. I've used a {{{~>}}} arrow to indicate fundeps. Is this a bug or am I missing something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12647: Can't capture improvement of functional dependencies
by GHC 13 Apr '17

13 Apr '17

#12647: Can't capture improvement of functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple FunctionalDependencies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [http://www.diku.dk/~paba/pubs/files/serrano15haskell-paper.pdf Type Families with Class, Type Classes with Family] discusses [https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70#pdf- instance-improvement instance improvement] with the example {{{#!hs class Collection c e | c -> e where empty :: c add :: e -> c -> c instance Collection [a] a where empty :: [a] empty = [] add :: a -> [a] -> [a] add = (:) }}} I wondered how to express that `x ~ Int` can be deduced from `Collection [Int] x` using improvement, I first attempted using the [https://hackage.haskell.org/package/constraints constraints] machinery: {{{#!hs data Dict c where Dict :: c => Dict c newtype a :- b = Sub (a => Dict b) }}} but I'm not able to construct a term of type `Collection [Int] x :- (Int ~ x)` proving that `Collection [Int] x` entails `Int ~ x`: {{{ ghci> Sub Dict :: Collection [Int] x :- (Int ~ x) <interactive>:52:5: error: • Couldn't match type ‘x1’ with ‘Int’ arising from a use of ‘Dict’ ‘x1’ is a rigid type variable bound by an expression type signature: forall x1. Collection [Int] x1 :- Int ~ x1 at <interactive>:52:13 • In the first argument of ‘Sub’, namely ‘Dict’ In the expression: Sub Dict :: Collection [Int] x :- (Int ~ x) In an equation for ‘it’: it = Sub Dict :: Collection [Int] x :- (Int ~ x) }}} Is this due to overlapping instances or something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12704: Check if constraint synonym satisfies functional dependencies
by GHC 13 Apr '17

13 Apr '17

#12704: Check if constraint synonym satisfies functional dependencies -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- When we resolve #12679, it will be possible to implement an abstract type class using a constraint synonym. However, in my implementation, I didn't implement functional dependency checking: {{{ signature H where class F a b | a -> b -- This should be an invalid implementation module H where type F a b = (Eq a, Eq b) }}} The check is annoying fiddly: we have to descend into the constraint synonym, collect all the implied fundeps, and then see if we have the ones we need, so I didn't implement it. Maybe some time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12763: Incorrect behavior with empty functional dependencies
by GHC 13 Apr '17

13 Apr '17

#12763: Incorrect behavior with empty functional dependencies -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (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: -------------------------------------+------------------------------------- This is a corner case, but it would appear that GHC doesn't do proper improvements for classes with "empty" functional dependencies. Consider the following example: {{{#!hs class C a | -> a where m :: a -> () instance C Int f x = m x }}} The inferred type for `f` is `C a => a -> ()`, however I was expecting it to infer `Int -> ()`. The reasoning is as follows: the use of `m` generates a `C a` constraint (`a` is a unification variable). This should have interacted with the `C Int` instance (in a rather odd vacuous sort of way) to generate a derived constraint `a ~ Int`, which should have then instantiated `a` to `Int`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13506: Spurious extra error message due to functional dependencies
by GHC 13 Apr '17

13 Apr '17

#13506: Spurious extra error message due to functional dependencies -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One call site is ill-typed, but GHC reports a type error at every call site, not just the problematic one. In the original code, the problem occurred with a very common function (`Data.Lens.view`), so the avalanche of error messages made it difficult to find the problematic call site. {{{#!hs {-# LANGUAGE FlexibleInstances, FunctionalDependencies, MultiParamTypeClasses #-} module Bug where class FunDep lista a | lista -> a instance FunDep [a] a singleton :: FunDep lista a => a -> lista singleton _ = undefined -- this error is expected: -- Couldn't match type 'Char' with '()' -- arising from a functional dependency between -- constraint 'FunDep [Char] ()' arising from a use of 'singleton' -- instance 'FunDep [a] a' illTyped :: [Char] illTyped = singleton () -- but this one is not: -- Couldn't match type '()' with 'Char' -- arising from a functional dependency between constraints: -- 'FunDep [Char] Char' arising from a use of 'singleton' (in 'wellTyped') -- 'FunDep [Char] ()' arising from a use of 'singleton' (in 'illTyped') wellTyped :: [Char] wellTyped = singleton 'a' }}} The spurious error disappears if `illTyped` is commented out or moved after `wellTyped`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13559: Remove LLVM/-fPIC check in DynFlags
by GHC 13 Apr '17

13 Apr '17

#13559: Remove LLVM/-fPIC check in DynFlags -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | 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: -------------------------------------+------------------------------------- When the LLVM backend was first implemented the implementation did not support `-fPIC` or `-dynamic`. Support for this was added in 60873542e8edf0ee593fde2b6544770d8036728f, which merely added the appropriate `-relocation-model` flag to the `opt` command line when compiling with `-fPIC`. However, the error message in `DynFlags.makeDynFlagsConsistent` remains for all but a select few platforms, {{{#!hs | hscTarget dflags == HscLlvm && not ((arch == ArchX86_64) && (os == OSLinux || os == OSDarwin || os == OSFreeBSD)) && not ((isARM arch) && (os == OSLinux)) && (gopt Opt_PIC dflags || WayDyn `elem` ways dflags) = if cGhcWithNativeCodeGen == "YES" then let dflags' = dflags { hscTarget = HscAsm } warn = "Using native code generator rather than LLVM, as LLVM is incompatible with -fPIC and -dynamic on this platform" in loop dflags' warn else throwGhcException $ CmdLineError "Can't use -fPIC or -dynamic on this platform" }}} Is this still necessary? If so, why? If not, we should remove it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7722: iOS patch no 11: Fix quirk with runtime loader
by GHC 13 Apr '17

13 Apr '17

#7722: iOS patch no 11: Fix quirk with runtime loader --------------------------------------+----------------------- Reporter: StephenBlackheath | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Other | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | --------------------------------------+----------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"68c00a1b38707b2a5c813cbe3da3ffb7d97893b6/ghc" 68c00a1b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68c00a1b38707b2a5c813cbe3da3ffb7d97893b6" Drop special handling of iOS iOS at least since iOS8 (we are currently at iOS10.3), allows for dynamic libaries, hence any artificail restriction on dyanmic libraries should be lifted. Please ping me with any iOS related issues that should potentially resurface. The iOS toolchain has considerably changed over the years, and I'm willing to drop work arounds in good faith. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13559, #7722 Differential Revision: https://phabricator.haskell.org/D3451 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7722#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13558: Inconsistency in `CoreUtils.exprIsOk`
by GHC 12 Apr '17

12 Apr '17

#13558: Inconsistency in `CoreUtils.exprIsOk` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- Consider {{{ f1 = \x y -> let t = case x of True -> let v = Just y in (v, v) False -> (Nothing, Nothing) in \w -> t f2 = \x y -> let t = case x of True -> (Just y, Just y) False -> (Nothing, Nothing) in \w -> t }}} We give `f1` arity 1, but `f2` gets arity 2. That's bizarre, because all we've done is turn a `let` into a function application. Reason: in `CoreUtils.exprIsOk`, we recursively apply `go` in the `App` case, but we fail unconditionally in the `Let` case. That is simply inconsistent, and it bit me when trying something else. Incidentally `exprIsOk` is badly named. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13160: Simplify CoreFV.FVAnn
by GHC 12 Apr '17

12 Apr '17

#13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- When introducing type-in-type, Richard elaborated the free varaible finder so that it finds three things at once (in `CoreFV`): {{{ data FVAnn = FVAnn { fva_fvs :: DVarSet -- free in expression , fva_ty_fvs :: DVarSet -- free only in expression's type , fva_ty :: Type -- expression's type } }}} I think `fva_ty` is needed only to support `fva_ty_fvs`. And `fva_ty_fvs` seems to be used only to support the calls to `freeVarsOfType` in `FloatIn`. And those calls in turn are only to suppor `used_in_ty` in `FloatIn.sepBindsByDropPoint`. In conversation yesterday, Richard and I agreed that all this is unnecessary. Coercion bindings simply do not float inwards, so we do not need to take these precautions. (We should add a Note to explain why they don't float, and what problem might arise if they did.) To confirm this I set `used_in_ty` to `False` and compiled from scratch; everything is fine. So I propose that we * get rid of the `ty_fvs` argument to `sepBindsByDropPoint` * simplfy `FVAnn` to just gather free variables (ie one field only) Result: it's all simpler. Richard will do this when he gets a moment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13138: Clean up ghc-pkg validation warnings in build log
by GHC 12 Apr '17

12 Apr '17

#13138: Clean up ghc-pkg validation warnings in build log -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- The build log has hundreds of lines of `ghc-pkg` warnings which I imagine are due to how GHC's build system is different to normal. We should either work out why there are so many errors and fix them or if they are harmless suppress them to remove the noise from the log. {{{ binary-0.8.3.0: Warning: Unrecognized field abi-depends on line 40 27 binary-0.8.3.0: Warning: Unrecognized field abi on line 28 28 binary-0.8.3.0: Warning: Unrecognized field indefinite on line 22 29 binary-0.8.3.0: Warning: haddock-interfaces: /var/drydock/workingcopy-21831/repo/glasgow-haskell- compiler/libraries/binary/dist-boot/doc/html/binary/binary.haddock doesn't exist or isn't a file 30 binary-0.8.3.0: cannot find any of ["Data/Binary.hi","Data/Binary.p_hi","Data/Binary.dyn_hi"] (ignoring) 31 binary-0.8.3.0: cannot find any of ["Data/Binary/Builder.hi","Data/Binary/Builder.p_hi","Data/Binary/Builder.dyn_hi"] (ignoring) 32 binary-0.8.3.0: cannot find any of ["Data/Binary/Get.hi","Data/Binary/Get.p_hi","Data/Binary/Get.dyn_hi"] (ignoring) 33 binary-0.8.3.0: cannot find any of ["Data/Binary/Get/Internal.hi","Data/Binary/Get/Internal.p_hi","Data/Binary/Get/Internal.dyn_hi"] (ignoring) 34 binary-0.8.3.0: cannot find any of ["Data/Binary/Put.hi","Data/Binary/Put.p_hi","Data/Binary/Put.dyn_hi"] (ignoring) 35 binary-0.8.3.0: cannot find any of ["Data/Binary/Class.hi","Data/Binary/Class.p_hi","Data/Binary/Class.dyn_hi"] (ignoring) 36 binary-0.8.3.0: cannot find any of ["Data/Binary/Internal.hi","Data/Binary/Internal.p_hi","Data/Binary/Internal.dyn_hi"] (ignoring) 37 binary-0.8.3.0: cannot find any of ["Data/Binary/Generic.hi","Data/Binary/Generic.p_hi","Data/Binary/Generic.dyn_hi"] (ignoring) 38 binary-0.8.3.0: cannot find any of ["libHSbinary-0.8.3.0.a","libHSbinary-0.8.3.0.p_a","libHSbinary-0.8.3.0-ghc7.10.3.so","libHSbinary-0.8.3.0-ghc7.10.3.dylib","HSbinary-0.8.3.0-ghc7.10.3.dll"] on library path (ignoring) 39 Cabal-1.25.0.0: Warning: Unrecognized field abi-depends on line 125 40 Cabal-1.25.0.0: Warning: Unrecognized field abi on line 106 41 Cabal-1.25.0.0: Warning: Unrecognized field indefinite on line 20 42 Cabal-1.25.0.0: Warning: haddock-interfaces: /var/drydock/workingcopy-21831/repo/glasgow-haskell- compiler/libraries/Cabal/Cabal/dist-boot/doc/html/Cabal/Cabal.haddock doesn't exist or isn't a file 43 Cabal-1.25.0.0: cannot find any of ["Distribution/Backpack.hi","Distribution/Backpack.p_hi","Distribution/Backpack.dyn_hi"] (ignoring) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2