July 2014 - ghc-tickets

[GHC] #9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl
by GHC 07 Jul '14

07 Jul '14

#9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I try to build the traverse-with-class package with GHC HEAD, I get an error: {{{ Data/Generics/Traversable/Instances.hs:21:1: Illegal type constructor or class name: ‘c’ When splicing a TH declaration: instance c_0 a_1 => Data.Generics.Traversable.Core.GTraversable c_0 (Data.Maybe.Maybe a_1) where Data.Generics.Traversable.Core.gtraverse = \f_2 x_3 -> case x_3 of Data.Maybe.Nothing -> Control.Applicative.pure Data.Maybe.Nothing Data.Maybe.Just arg_4 -> (Control.Applicative.<*>) (Control.Applicative.pure Data.Maybe.Just) (f_2 arg_4) }}} This code used to compile with all the previous versions. Additionally, if I replace the TH splice with the generated instance declaration (with minimal corrections to make all names resolve), it is accepted: {{{ instance c_0 a_1 => Data.Generics.Traversable.Core.GTraversable c_0 (Maybe a_1) where gtraverse = \f_2 x_3 -> case x_3 of Nothing -> Control.Applicative.pure Nothing Just arg_4 -> (Control.Applicative.<*>) (Control.Applicative.pure Just) (f_2 arg_4) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9283: bad autoconf variable names
by GHC 07 Jul '14

07 Jul '14

#9283: bad autoconf variable names ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ if test "$ac_cv_header_sys_epoll_h" = yes -a "$ac_cv_func_epoll_ctl" = yes; then AC_DEFINE([HAVE_EPOLL], [1], [Define if you have epoll support.]) fi if test "$ac_cv_header_sys_event_h" = yes -a "$ac_cv_func_kqueue" = yes; then AC_DEFINE([HAVE_KQUEUE], [1], [Define if you have kqueue support.]) AC_CHECK_SIZEOF([kev.filter], [], [#include <sys/event.h> struct kevent kev;]) AC_CHECK_SIZEOF([kev.flags], [], [#include <sys/event.h> struct kevent kev;]) fi if test "$ac_cv_header_poll_h" = yes -a "$ac_cv_func_poll" = yes; then AC_DEFINE([HAVE_POLL], [1], [Define if you have poll support.]) fi }}} The `AC_DEFINE` lines for `HAVE_KQUEUE` and `HAVE_POLL` don't do anything, because earlier we have {{{ AC_CHECK_FUNCS([epoll_ctl eventfd kevent kevent64 kqueue poll]) }}} and that already defines `HAVE_KQUEUE` (and sets `ac_cv_func_kqueue`) when the `kqueue` function is found. Not entirely sure what the right thing to do is here, do we rely on having a prototype for `kqueue` in `sys/event.h` specifically? Technically that wouldn't be what we check for even if we used a renamed `HAVE_KQUEUE` variable. AFAIK this doesn't cause any real problems except that it really confused me when I tried to simulate not having `poll` by moving `/usr/include/poll.h` away temporarily. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5610: Improve "Unacceptable argument type in foreign declaration" error message
by GHC 07 Jul '14

07 Jul '14

#5610: Improve "Unacceptable argument type in foreign declaration" error message -------------------------------------------------+------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.6.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by mietek): With 7.8.2, using `import Foreign.C.Types (CInt)` still results in the unclear error message: {{{ Unacceptable argument type in foreign declaration: CInt }}} Using `import Foreign.C.Types (CInt (..))` helps, but should this be required? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5610#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9275: Missing import statement in GHC.Event.Poll
by GHC 06 Jul '14

06 Jul '14

#9275: Missing import statement in GHC.Event.Poll ----------------------------------+---------------------------------------- Reporter: ydewit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- See the following section from base's GHC.Event.Poll module: {{{ module GHC.Event.Poll ( new , available ) where #include "EventConfig.h" #if !defined(HAVE_POLL_H) import GHC.Base new :: IO E.Backend new = error "Poll back end not implemented for this platform" available :: Bool available = False {-# INLINE available #-} #else #include <poll.h> import Control.Concurrent.MVar (MVar, newMVar, swapMVar) import Control.Monad ((=<<), liftM, liftM2, unless) import Data.Bits (Bits, FiniteBits, (.|.), (.&.)) import Data.Maybe (Maybe(..)) import Data.Monoid (Monoid(..)) import Data.Word import Foreign.C.Types (CInt(..), CShort(..)) import Foreign.Ptr (Ptr) import Foreign.Storable (Storable(..)) import GHC.Base import GHC.Conc.Sync (withMVar) import GHC.Enum (maxBound) import GHC.Num (Num(..)) import GHC.Real (ceiling, fromIntegral) import GHC.Show (Show) import System.Posix.Types (Fd(..)) import qualified GHC.Event.Array as A import qualified GHC.Event.Internal as E }}} Note how there is a missing {{{import qualified GHC.Event.Internal as E}}} when {{{HAVE_POLL_H}}} is not defined. The same issue is present in master. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9277: audit ghc floating point support for IEEE (non)compliance
by GHC 06 Jul '14

06 Jul '14

#9277: audit ghc floating point support for IEEE (non)compliance ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 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 best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation. This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to: a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point. (this may grow into a few subtickets, we'll see) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9273: TypeNats and record syntax don't compile
by GHC 05 Jul '14

05 Jul '14

#9273: TypeNats and record syntax don't compile -------------------------------------+------------------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ #!haskell data SNat :: Nat -> * where SNatZ :: SNat 0 SNatS :: {sNatPred :: SNat n} -> SNat (n+1) }}} gives error {{{ rec_gadt_nat.hs:13:13: Could not deduce (n1 ~ n) from the context ((n + 1) ~ (n1 + 1)) bound by a pattern with constructor SNatS :: forall (n :: Nat). SNat n -> SNat (n + 1), in an equation for ‘sNatPred’ at rec_gadt_nat.hs:13:13-20 ‘n1’ is a rigid type variable bound by a pattern with constructor SNatS :: forall (n :: Nat). SNat n -> SNat (n + 1), in an equation for ‘sNatPred’ at rec_gadt_nat.hs:13:13 ‘n’ is a rigid type variable bound by the type signature for sNatPred :: SNat (n + 1) -> SNat n at rec_gadt_nat.hs:13:13 Expected type: SNat n Actual type: SNat n1 Relevant bindings include sNatPred :: SNat n1 (bound at rec_gadt_nat.hs:13:13) sNatPred :: SNat (n + 1) -> SNat n (bound at rec_gadt_nat.hs:13:13) In the expression: sNatPred In an equation for ‘sNatPred’: sNatPred (SNatS {sNatPred = sNatPred}) = sNatPred }}} while {{{ #!haskell data SNat :: Nat -> * where SNatZ :: SNat 0 SNatS :: SNat n -> SNat (n+1) }}} works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9273> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3178: Fix linking -lpthread for semaphores
by GHC 04 Jul '14

04 Jul '14

#3178: Fix linking -lpthread for semaphores -----------------------------------+------------------------------------ Reporter: sthibaul | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: libraries/unix | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Other | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4523 -----------------------------------+------------------------------------ Changes (by thomie): * status: new => closed * resolution: => fixed * related: => #4523 Comment: This issue should be fixed together with ticket #4523, commit [http://git.haskell.org/packages/unix.git/commit/dd0178b4803924d832622436261… dd0178b]. Proper autoconf test for sem_close's library; fixes trac #4523 Note: the current issue tracker for the `unix` library is at https://github.com/haskell/unix/issues -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3178#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 04 Jul '14

04 Jul '14

#6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak@… (removed) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 04 Jul '14

04 Jul '14

#6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by goldfire): I thinking about this ticket, I've imagined some syntax like this: {{{ type family FullyInjective a | Result -> a -- use a fun-dep-like syntax, where "Result" is a keyword, capitalized to avoid name-clashes with type variables type family Plus a b | Result a -> b, Result b -> a type family Only1stInjective a b | Result -> a }}} I could even imagine having dependencies among the arguments, though that might be a little strange. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4259: Relax restrictions on type family instance overlap
by GHC 04 Jul '14

04 Jul '14

#4259: Relax restrictions on type family instance overlap --------------------------------------------+------------------------------ Reporter: lilac | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8423 --------------------------------------------+------------------------------ Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4259#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0