January 2016 - ghc-tickets

Re: [GHC] #5063: unix package has untracked dependency on libbsd
by GHC 19 Jan '16

19 Jan '16

#5063: unix package has untracked dependency on libbsd -------------------------------------+------------------------------------- Reporter: duncan | Owner: trommler Type: bug | Status: upstream Priority: low | Milestone: 8.2.1 Component: Core Libraries | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:15 bgamari]: > What is the status of this? It seems like there have been no patches submitted upstream to resolve this. Tbh, based on > If the system that the package is built on has libbsd installed then it'll use it. But if the target system does not have this C lib then the HsUnix.h header is broken on such systems. This doesn't sound like an issue in `unix`, but rather an inherent issue with binaries built on a build-environment which is different from the target/deployment environment. I wouldn't consider this a bug in `unix`. It works as designed, as `unix` when configured tries to use as many features as available in the build environment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5063#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11379: New superclass solver fails to compile
by GHC 19 Jan '16

19 Jan '16

#11379: New superclass solver fails to compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- This example (derived from `xmonad-contrib`) failed to compile with `master`, {{{#!hs {-# LANGUAGE ExistentialQuantification, RankNTypes, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, FlexibleContexts #-} module XMonad.Layout.MultiToggle where import Data.Typeable -- This appears to be the culprit expand :: (HList ts a) => MultiToggleS ts l a -> MultiToggle ts l a expand (MultiToggleS b ts) = resolve ts id (\x mt -> let g = transform' x in mt{ currLayout = g $ currLayout mt }) (MultiToggle (EL b id) ts) class (Typeable t) => Transformer t a | t -> a where transform :: t -> l a -> (forall l'. l' a -> (l' a -> l a) -> b) -> b data EL l a = forall l'. EL (l' a) (l' a -> l a) transform' :: (Transformer t a) => t -> EL l a -> EL l a transform' t (EL l det) = undefined data MultiToggleS ts l a = MultiToggleS (l a) ts deriving (Read, Show) data MultiToggle ts l a = MultiToggle{ currLayout :: EL l a, transformers :: ts } class HList c a where resolve :: c -> b -> (forall t. (Transformer t a) => t -> b) -> b }}} failing during constraint solving with,, {{{ XMonad/Layout/MultiToggle.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [D] _ :: Transformer t a (CDictCan) [D] _ :: a_aIoy ~ a (CNonCanonical) [D] _ :: Typeable t (CDictCan) wc_impl = Implic { TcLevel = 7 Skolems = (l :: * -> *) No-eqs = True Status = Unsolved Given = Wanted = WC {wc_simple = [W] $dTransformer_aIoM :: Transformer t a (CDictCan)} Binds = Just EvBindsVar<aIoN> the inferred type of g :: EL l_aIoL a_aIoK -> EL l_aIoL a_aIoK }} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit }}} Lifting the solver iteration limit just results in a loop. I suspect the issue may be in the `Typeable` solving logic, as removing the `Typable` constraint from `Transformer`'s head allows compilation to proceed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11379> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7888: Impredicativity flag needed more often
by GHC 19 Jan '16

19 Jan '16

#7888: Impredicativity flag needed more often -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T7888 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is at odds with #11431. I'm going with #11431 as that's more consistent, as discussed on that ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7888#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5916: runST isn't free
by GHC 19 Jan '16

19 Jan '16

#5916: runST isn't free -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_run/runST Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: The new `runRW#` primop is just what the doctor ordered. See 351de169e14ad9277aaca653df4a3753c151f7bb -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5916#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2988: Improve float-in
by GHC 19 Jan '16

19 Jan '16

#2988: Improve float-in -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 6.10.1 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task * milestone: 8.0.1 => 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2988#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss"
by GHC 19 Jan '16

19 Jan '16

#11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.0.1-rc1 system | 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 I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently: {{{ $ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock- ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set- cover-0.0.8.tar.gz Downloading http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz Resolving dependencies... Configuring enummapset-0.5.2.1... Building enummapset-0.5.2.1... Preprocessing library enummapset-0.5.2.1... [1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o ) ... [4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o ) [5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o ) In-place registering enummapset-0.5.2.1... Running Haddock for enummapset-0.5.2.1... Preprocessing library enummapset-0.5.2.1... ... Registering enummapset-0.5.2.1... Installed enummapset-0.5.2.1 Configuring set-cover-0.0.8... Building set-cover-0.0.8... Preprocessing library set-cover-0.0.8... [ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o ) [ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o ) src/Math/SetCover/Queue.hs:3:1: error: Bad interface file: /home/cabal/lib/x86_64-linux- ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap src/Math/SetCover/Queue.hs:4:1: error: Bad interface file: /home/cabal/lib/x86_64-linux- ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet Failed to install set-cover-0.0.8 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11455> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives
by GHC 19 Jan '16

19 Jan '16

#10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: parallelim | 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 example code in GHC 7.10.2 docs "7.28. Concurrent and Parallel Haskell", then in "7.15.4. Annotating pure code for parallelism" the recommendation is to use `par` and `pseq`. These primitives pre-dates the strategy combinators `rpar` and `rseq`. The example given is: {{{#!hs import Control.Parallel nfib :: Int -> Int nfib n | n <= 1 = 1 | otherwise = par n1 (seq n2 (n1 + n2 + 1)) where n1 = nfib (n-1) n2 = nfib (n-2) }}} The paper "Seq no more: Better Strategies for Parallel Haskell" ([http://www.macs.hw.ac.uk/~hwloidl/publications/strategies10.pdf] advocates `Eval` as an "evaluation order" monad, as preferable (versus `par` and `seq`) for loose control of evaluation order of parallelism. Moreover, Simon Marlow's "Parallel and Concurrent Programming in Haskell" doesn't mention the `par` and `seq` primitives at all. Should the GHC docs for "Concurrent and Parallel Haskell" encourage the use Eval combinators, either in addition to or instead of the `par` and `seq` primitives? I'd be happy to contribute an update to the docs if people agree to a shift in emphasis towards the Eval monad in the docs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11453: Kinds in type synonym/data declarations can unexpectedly unify
by GHC 19 Jan '16

19 Jan '16

#11453: Kinds in type synonym/data declarations can unexpectedly unify -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying out ideas to fix [https://github.com/ekmett/lens/issues/626 this lens issue], I noticed a couple of peculiar things about kinds in type synonym and data declarations. For example: {{{ $ /opt/ghc/head/bin/ghci -XTypeInType -XRankNTypes -XTypeOperators GHCi, version 8.1.20160113: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/xnux/.ghci λ> import Data.Kind λ> type Wat (a :: k2) (b :: k3) = forall (f :: k1 -> *). Either (f a) (f b) λ> :i Wat type Wat (a :: k1) (b :: k1) = forall (f :: k1 -> *). Either (f a) (f b) -- Defined at <interactive>:2:1 }}} This is pretty odd for two reasons. One, the kind {{{k1}}} was never specified (either existentially or as a visible kind binder), so that definition should have been rejected. But even if we do use an existential kind: {{{ λ> type Wat (a :: k2) (b :: k3) = forall k1 (f :: k1 -> *). Either (f a) (f b) λ> :i Wat type Wat (a :: k1) (b :: k1) = forall k2 (f :: k2 -> *). Either (f a) (f b) -- Defined at <interactive>:4:1 }}} We still see the second issue: GHC thinks that the type variables `a` and `b` have the same kind `k1`, when they should have separate kinds `k1` and `k2`! That behavior is very surprising to me, since it seems like GHC is choosing to unify two kind variables that should be rigid. Note that this doesn't happen if you use explicit kind binders: {{{ type Wat k2 k3 (a :: k2) (b :: k3) = forall k1 (f :: k1 -> *). Either (f a) (f b) <interactive>:6:74: error: • Expected kind ‘k1’, but ‘a’ has kind ‘k2’ • In the first argument of ‘f’, namely ‘a’ In the first argument of ‘Either’, namely ‘f a’ In the type ‘forall k1 (f :: k1 -> *). Either (f a) (f b)’ <interactive>:6:80: error: • Expected kind ‘k1’, but ‘b’ has kind ‘k3’ • In the first argument of ‘f’, namely ‘b’ In the second argument of ‘Either’, namely ‘f b’ In the type ‘forall k1 (f :: k1 -> *). Either (f a) (f b)’ }}} only when the kinds are specified but not visible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 19 Jan '16

19 Jan '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by rassilon): Replying to [comment:49 thomie]: > rassilon: you seem to know stuff. How to fix dynamic linking on Windows? Some more problems here: #4824 #5620 #7665 #8228. The "easiest" way of fixing this issue is by refactoring the GHC internals in such a way as to minimize the dependencies between the partitions of the GHC base DLL. (in short, removing all need for Haskell source level cyclic imports could help a bunch here) Either that, or come up with an automatic partitioning scheme that could handle cyclic references between the partition DLLs. The PE/COFF limitation of only being able to export 16bits worth of APIs from a dynamic library is the biggest problem of all of these issues. #5620 would only be worth addressing when we have a solution to this issue one way or another. Given that the root of the 16bit exported API problem stems from the PE/COFF specification, it would seem that any alternatives we come up would be conceptually equivalent to our current usages of non-dlopen(or equivalent) dynamic loading/linking that RTS/GHCi do today. In fact the code necessary to fix this issue would probably make that logic even more convoluted and difficult to understand/maintain. (Since the code would need to understand whatever additional sections/per-DLL API functions/etc.. that would allow the code to be relocated and linked properly.) Such a scheme would have additional downsides as well: * It would be (by necessity) be Windows specific. * It would probably completely shatter the mechanism for calling Haskell functions from C/C++ either in the same DLL or another DLL. Of the possible above approaches, I would think an automatic partitioning approach that handled cyclic references between the partitions would be the approach that had the best long term chances of successfully being maintained. Having said that of course, even automatic partitioning is still a non trivial amount of work. Since ideally, Cabal would know about DLL partitioning as well so that when anyone referenced a Haskell package with partitions, Cabal would help (or direct) GHC to link against all of the partition DLLs of that package. Ugh. Maybe it'll be easier once Microsoft lets us push a pull request to Window's dynamic linker to support more than 16bits of ordinals for Windows 20. ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 19 Jan '16

19 Jan '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by thomie): rassilon: you seem to know stuff. How to fix dynamic linking on Windows? Some more problems here: #4824 #5620 #7665 #8228. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0