November 2014 - ghc-tickets

[GHC] #9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl
by GHC 07 Nov '14

07 Nov '14

#9755: Monomorphism related Ix/Vector error when code is loaded by GHCi/cabal repl -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE BangPatterns #-} import Data.Vector (Vector, (!)) import qualified Data.Vector as Vec import Data.Ix (Ix) import qualified Data.Ix as Ix vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a vecIndexIx vec ix = vec ! Ix.index (minBound :: ix, maxBound :: ix) ix vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a vecCreateIx f = Vec.fromListN (Ix.rangeSize bounds) [ y | ix <- Ix.range bounds, let !y = f ix ] where bounds = (minBound, maxBound) }}} The following errors occur: {{{ GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l cabal cabal.sandbox.config cabal_problem.hs Prelude> :l cabal_problem.hs [1 of 1] Compiling Main ( cabal_problem.hs, interpreted ) cabal_problem.hs:9:37: Could not deduce (Bounded ix1) arising from a use of ‘minBound’ from the context (Ix ix, Bounded ix) bound by the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a at cabal_problem.hs:8:16-57 Possible fix: add (Bounded ix1) to the context of an expression type signature: ix1 or the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a In the expression: minBound :: ix In the first argument of ‘Ix.index’, namely ‘(minBound :: ix, maxBound :: ix)’ In the second argument of ‘(!)’, namely ‘Ix.index (minBound :: ix, maxBound :: ix) ix’ cabal_problem.hs:9:53: Could not deduce (Bounded ix1) arising from a use of ‘maxBound’ from the context (Ix ix, Bounded ix) bound by the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a at cabal_problem.hs:8:16-57 Possible fix: add (Bounded ix1) to the context of an expression type signature: ix1 or the type signature for vecIndexIx :: (Ix ix, Bounded ix) => Vector a -> ix -> a In the expression: maxBound :: ix In the first argument of ‘Ix.index’, namely ‘(minBound :: ix, maxBound :: ix)’ In the second argument of ‘(!)’, namely ‘Ix.index (minBound :: ix, maxBound :: ix) ix’ cabal_problem.hs:12:32: Could not deduce (Ix a0) arising from a use of ‘Ix.rangeSize’ from the context (Ix ix, Bounded ix) bound by the type signature for vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a at cabal_problem.hs:11:16-59 The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance Ix () -- Defined in ‘GHC.Arr’ instance (Ix a, Ix b) => Ix (a, b) -- Defined in ‘GHC.Arr’ instance (Ix a1, Ix a2, Ix a3) => Ix (a1, a2, a3) -- Defined in ‘GHC.Arr’ ...plus 8 others In the first argument of ‘Vec.fromListN’, namely ‘(Ix.rangeSize bounds)’ In the expression: Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] In an equation for ‘vecCreateIx’: vecCreateIx f = Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] where bounds = (minBound, maxBound) cabal_problem.hs:12:45: Could not deduce (Bounded a0) arising from a use of ‘bounds’ from the context (Ix ix, Bounded ix) bound by the type signature for vecCreateIx :: (Ix ix, Bounded ix) => (ix -> a) -> Vector a at cabal_problem.hs:11:16-59 The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance Bounded Data.Monoid.All -- Defined in ‘Data.Monoid’ instance Bounded Data.Monoid.Any -- Defined in ‘Data.Monoid’ instance Bounded a => Bounded (Data.Monoid.Dual a) -- Defined in ‘Data.Monoid’ ...plus 23 others In the first argument of ‘Ix.rangeSize’, namely ‘bounds’ In the first argument of ‘Vec.fromListN’, namely ‘(Ix.rangeSize bounds)’ In the expression: Vec.fromListN (Ix.rangeSize bounds) [y | ix <- Ix.range bounds, let !y = f ix] Failed, modules loaded: none. }}} The remedy was in this pull request https://github.com/haskell/hackage- server/pull/273/files under the file "Distribution/Server/Features/Search/DocTermIds.hs" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9755> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9770: GHC Parser fails on Haddock comment on parameter of a function record field
by GHC 07 Nov '14

07 Nov '14

#9770: GHC Parser fails on Haddock comment on parameter of a function record field -------------------------------------+------------------------------------- Reporter: boris | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: Haddock | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I tried to document parameter of a function that is a record field. The Haddock fails with parse error on input ‘->’ {{{ data D = D { field :: () -- ^ parameter -> () } }}} Please see https://github.com/haskell/haddock/issues/343 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9714: Un-`wire` Integer type
by GHC 07 Nov '14

07 Nov '14

#9714: Un-`wire` Integer type -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: Integer | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: #9281 | Blocking: | Differential Revisions: Phab:351 -------------------------------------+------------------------------------- `Integer` is currently a wired-in type for `integer-gmp`. This requires replicating its inner structure in `TysWiredIn.lhs`, which makes it much harder to change `Integer` to a more complex representation (like e.g. for #9281) In order to reduce the redundancy (due to wired-in type mirroring) and simplify the code, as [http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5823/ suggested by Simon], `Integer` should no longer be a `wired-in` type but rather become a `known-key`-entity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable
by GHC 07 Nov '14

07 Nov '14

#9761: A module can't usefully use both GeneralizedNewtypeDeriving and DeriveFoldable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If GND is enabled, and roles don't permit a `Foldable` instance to be derived, it won't fall back on `DeriveFoldable`; instead it just produces an error. I think ideally I'd want to use a pragma to state explicitly that I want to use `DeriveFoldable`-style deriving for this specific instance, but an implicit fallback would be acceptable. {{{#!hs {-# LANGUAGE -- GeneralizedNewtypeDeriving, DeriveFoldable #-} module Derive where import qualified Data.IntMap as M newtype UniqFM ele = UFM {unUFM :: M.IntMap ele} deriving (Foldable) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9759: Add Alternative wrapper to Data.Monoid
by GHC 07 Nov '14

07 Nov '14

#9759: Add Alternative wrapper to Data.Monoid -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As discussed on the libraries list, {{{#!hs -- | Monoid under @<|>@. newtype Alt f a = Alt {getAlt :: f a} deriving (Generic, Generic1, Read, Show, Eq, Ord, Num, Enum, Monad, MonadPlus, Applicative, Alternative, Functor) instance forall f a . Alternative f => Monoid (Alt f a) where mempty = Alt empty mappend = coerce ((<|>) :: f a -> f a -> f a) }}} The documentation for `Data.Monoid.First` and `Data.Monoid.Last` should also be expanded to explain that `First a` is isomorphic to `Alt Maybe a` and `Last a` is isomorphic to `Dual (Alt Maybe a)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9742: The default definitions of foldl1 and foldr1 are too strict
by GHC 07 Nov '14

07 Nov '14

#9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We currently have {{{#!hs foldr1 :: (a -> a -> a) -> t a -> a foldr1 f xs = fromMaybe (error "foldr1: empty structure") (foldr mf Nothing xs) where mf x Nothing = Just x mf x (Just y) = Just (f x y) }}} This has to traverse the entire list before it can do anything. What we want is {{{#!hs mf x r = Just $ case r of Nothing -> x Just y -> f x y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8828: allow fully applied type families in instance heads
by GHC 07 Nov '14

07 Nov '14

#8828: allow fully applied type families in instance heads ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, it would be nice if the following example were acceptable: {{{ {-# LANGUAGE FlexibleInstances, TypeFamilies, TypeSynonymInstances #-} data X a = X a type family TX a type instance TX a = X a instance Show (TX Int) }}} But ghc complains that it cannot substitute the instance of TX: {{{ ts.hs:6:10: Illegal type synonym family application in instance: TX Int In the instance declaration for ‛Show (TX Int)’ }}} A more practical (but not self-contained) example involving extensible records looks http://lpaste.net/100436 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9295: Deadlock in forkProcess
by GHC 07 Nov '14

07 Nov '14

#9295: Deadlock in forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As part of `forkProcess` we discard all tasks except the one task that remains. As part of this we call `freeTask`, and `freeTask` in turn calls `closeCondition` and `closeMutex`, which are very thin wrappers around `pthread_cond_destroy` and `phread_mutex_destroy`. However, the behaviour of these functions is undefined when there are currently threads blocked on these condition variables/mutexes. In reality, this undefined behaviour often (though not always) results in a deadlock. Unfortunately, I don't have a minimal test case to demonstrate this, but in the large system on which I am testing this I am seeing these deadlocks rather frequently. For the global mutex we don't attempt to call `pthread_cond_destroy` or `pthread_mutex_destroy`, but instead re-initialize them. The patch https://phabricator.haskell.org/D59 does precisely that for the condition variables and mutexes associated with tasks. This is ''somewhat'' or a long way around, because we will then subsequently still call `pthread_..._destroy`, but it means that we don't have to mess with `freeTask`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2528: documentation for nub and nubBy should be corrected, extended or removed.
by GHC 07 Nov '14

07 Nov '14

#2528: documentation for nub and nubBy should be corrected, extended or removed. -------------------------------------+------------------------------------- Reporter: jdressel | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.8.2 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@… (added) * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2528#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7913: Argument order not preserved by nubBy
by GHC 07 Nov '14

07 Nov '14

#7913: Argument order not preserved by nubBy -------------------------------------+------------------------------------- Reporter: paullik | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Prelude | Version: 7.6.3 Resolution: fixed | Keywords: nubBy Operating System: Linux | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7913#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0