- ghc-tickets - Haskell.org

Re: [GHC] #2721: Newtype deriving doesn't work with type families
by GHC 24 Oct '16

24 Oct '16

#2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #8165 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2721#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12761: Type aliases for TypeError constrains fire during compilation time
by GHC 24 Oct '16

24 Oct '16

#12761: Type aliases for TypeError constrains fire during compilation time -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! The following code should compile fine: {{{ module Main where import GHC.TypeLits (ErrorMessage(Text, ShowType, (:<>:)), TypeError) type MyError a b = TypeError (ShowType a :<>: ShowType b) main :: IO () main = return () }}} but it raises an error during compilation: {{{ Main.hs:5:1: error: • ab • In the type synonym declaration for ‘MyError’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7808: data families and TH names do not mix well (e.g. cannot use TH deriving)
by GHC 24 Oct '16

24 Oct '16

#7808: data families and TH names do not mix well (e.g. cannot use TH deriving) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Apologies for commenting on an extremely old Trac ticket. The way I tackle this problem in libraries like `bifunctors` (see [http://hackage.haskell.org/package/bifunctors-5.4.1/docs/Data-Bifunctor- TH.html#v:deriveBifunctor Data.Bifunctor.TH]) is by allowing functions of the form `:: Name -> Q a` to take either a type constructor `Name` (for a plain datatype) or a data constructor `Name` (for a data family instance). The TH code is able to look up the original data family instance from any of its data constructor names, so it works, although it's a bit awkward. There's also the drawback that you can't do this trick for data family instances with no constructors... but how useful are those, really? :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7808#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another)
by GHC 24 Oct '16

24 Oct '16

#12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Still trying to debug compilation failures in our codebase, still can't build prerequisites yet. ghc needs to be compiled with BuildVlavour = devel2 and compilation with -O2 is required: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} module A where import Data.List(minimumBy) import Data.Ord (comparing) data A a = A Int newtype B = B Double deriving (Eq,Ord,Num,Real,Fractional,RealFrac,Floating,RealFloat) class C a where _c :: [a] -> D a instance C B where _c = f2 u data D x = D [(x,Double)] [ x ] u = undefined f1 :: RealFloat a => A a -> a -> [a] -> D a f1 (A a1) m ps0 = D (zip tickvs []) labelvs where range _ | m == m = if m==0 then (-1,1) else (m, m) labelvs = map fromRational $ f3 (fromIntegral a1) (range ps0) tickvs = map fromRational $ f3 (fromIntegral a1) (head labelvs, head labelvs) f2 :: RealFloat a => A a -> [a] -> D a f2 lap ps = f1 u (minimum ps) ps f3 :: RealFloat a => a -> (a,a) -> [Rational] f3 k rs@(m,_ ) = map ((s*) . fromIntegral) [floor m .. ] where s = minimumBy (comparing ((+ k) . realToFrac)) [0] }}} {{{ % ghc -O2 A.hs [1 of 1] Compiling A ( A.hs, A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1978:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2014:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1454:33 in ghc:Coercion in_scope InScope [00 :-> wild_00, X1o :-> wild_X1o, X1p :-> wild_X1p, a4z5 :-> $c==_a4z5, a4zs :-> $c/=_a4zs, a4zV :-> $ccompare_a4zV, a4Ai :-> $c<_a4Ai, a4AF :-> $c<=_a4AF, a4B2 :-> $c>_a4B2, a4Bp :-> $c>=_a4Bp, a4BM :-> $cmax_a4BM, a4C9 :-> $cmin_a4C9, a4Cy :-> $c+_a4Cy, a4CV :-> $c-_a4CV, a4Di :-> $c*_a4Di, a4DF :-> $cnegate_a4DF, a4DY :-> $cabs_a4DY, a4Eh :-> $csignum_a4Eh, a4EA :-> $cfromInteger_a4EA, a4F3 :-> $ctoRational_a4F3, a4Fs :-> $c/_a4Fs, a4FP :-> $crecip_a4FP, a4G8 :-> $cfromRational_a4G8, a4GB :-> $cproperFraction_a4GB, a4Hg :-> $ctruncate_a4Hg, a4HV :-> $cround_a4HV, a4IA :-> $cceiling_a4IA, a4Jf :-> $cfloor_a4Jf, a4K0 :-> $cpi_a4K0, a4Kf :-> $cexp_a4Kf, a4Ky :-> $clog_a4Ky, a4KR :-> $csqrt_a4KR, a4La :-> $c**_a4La, a4Lx :-> $clogBase_a4Lx, a4LU :-> $csin_a4LU, a4Md :-> $ccos_a4Md, a4Mw :-> $ctan_a4Mw, a4MP :-> $casin_a4MP, a4N8 :-> $cacos_a4N8, a4Nr :-> $catan_a4Nr, a4NK :-> $csinh_a4NK, a4O3 :-> $ccosh_a4O3, a4Om :-> $ctanh_a4Om, a4OF :-> $casinh_a4OF, a4OY :-> $cacosh_a4OY, a4Ph :-> $catanh_a4Ph, a4PA :-> $clog1p_a4PA, a4PT :-> $cexpm1_a4PT, a4Qc :-> $clog1pexp_a4Qc, a4Qv :-> $clog1mexp_a4Qv, a4QY :-> $cfloatRadix_a4QY, a4Rh :-> $cfloatDigits_a4Rh, a4RA :-> $cfloatRange_a4RA, a4RT :-> $cdecodeFloat_a4RT, a4Sc :-> $cencodeFloat_a4Sc, a4Sz :-> $cexponent_a4Sz, a4SS :-> $csignificand_a4SS, a4Tb :-> $cscaleFloat_a4Tb, a4Ty :-> $cisNaN_a4Ty, a4TR :-> $cisInfinite_a4TR, a4Ua :-> $cisDenormalized_a4Ua, a4Ut :-> $cisNegativeZero_a4Ut, a4UM :-> $cisIEEE_a4UM, a4V5 :-> $catan2_a4V5, a4Vu :-> $c_c_a4Vu, a5eH :-> wild_a5eH, a5eJ :-> x_a5eJ, ruN :-> u, ruO :-> f1, ruP :-> f2, ruQ :-> f3, r24E :-> $tc'A, r25L :-> $tcA, r25N :-> $tc'B, r25Z :-> $tcB, r2dl :-> $tc'D, r2ds :-> $tcD, r2dF :-> $tcC, r2dG :-> $tc'C:C, r2dL :-> $fCB, r2dZ :-> $fEqB, r2ec :-> $fOrdB, r2nC :-> $fNumB, r2nK :-> $fRealB, r2nT :-> $fFractionalB, r2oa :-> $fRealFracB, r2oC :-> $fFloatingB, r2oX :-> $fRealFloatB, r4yJ :-> $trModule, s5iM :-> $trModule_s5iM, s5iN :-> $trModule_s5iN, s5iO :-> $tc'A_s5iO, s5iQ :-> $tc'B_s5iQ, s5iR :-> $tcB_s5iR, s5iS :-> $tc'D_s5iS, s5iT :-> $tcD_s5iT, s5iU :-> $tc'C:C_s5iU, s5iV :-> $tcC_s5iV, s5jw :-> $sf2_s5jw, s5jM :-> $sf1_s5jM, s5jU :-> labelvs_s5jU, s5k8 :-> $sf3_s5k8, s5ki :-> $sfromIntegral_s5ki, s5kD :-> $sminimum_s5kD, s5kE :-> $scomparing_s5kE, s5kF :-> $srealToFrac_s5kF, s5kG :-> $sfromIntegral_s5kG, s5kN :-> lvl_s5kN, s5kX :-> lvl_s5kX, s5lc :-> lvl_s5lc, s5ln :-> lvl_s5ln, s5pu :-> lvl_s5pu, s5pv :-> lvl_s5pv, s5ra :-> lvl_s5ra, s5rb :-> lvl_s5rb, s5Bi :-> $w$sf3_s5Bi, s5Bt :-> $wf3_s5Bt, s5Bx :-> w_s5Bx, s5BB :-> ww_s5BB, s5BF :-> $w$sf1_s5BF, s5BS :-> $wf1_s5BS, s5BW :-> $wf2_s5BW, s5D0 :-> $j_s5D0, s5FJ :-> lvl_s5FJ, s5FL :-> $wgo_s5FL, s5FM :-> lvl_s5FM, s5FN :-> lvl_s5FN, s5FP :-> karg_s5FP, s5FW :-> go_s5FW, s5FX :-> lvl_s5FX, s5FY :-> lvl_s5FY, s5FZ :-> lvl_s5FZ, s5G0 :-> lvl_s5G0, s5G1 :-> lvl_s5G1, s5G2 :-> lvl_s5G2, s5G4 :-> lvl_s5G4, s5G5 :-> lvl_s5G5, s5G6 :-> lvl_s5G6, s5G7 :-> lvl_s5G7, s5Io :-> $s$j_s5Io, s5Ip :-> $s$j_s5Ip, s5Ir :-> $sgo_s5Ir] tenv [] tenvFVs [] cenv [s5Ij :-> sg_s5Ij, s5Ik :-> sg_s5Ik] cenvFVs [s5Ij :-> sg_s5Ij, s5Ik :-> sg_s5Ik] tys [Ratio Integer] cos [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12427: Type inference regression with RankNTypes (GHC 8.1)
by GHC 24 Oct '16

24 Oct '16

#12427: Type inference regression with RankNTypes (GHC 8.1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: RankNTypes | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following module compiles fine with ghc-8.0.1: {{{#!hs {-# LANGUAGE RankNTypes #-} module Acquire where newtype Acquire a = Acquire {unAcquire :: (forall b. b -> b) -> IO a} instance Functor Acquire where fmap = undefined instance Applicative Acquire where pure = undefined (<*>) = undefined instance Monad Acquire where Acquire f >>= g' = Acquire $ \restore -> do x <- f restore let Acquire g = g' x -- let g = unAcquire (g' x) g restore }}} HEAD (83e4f49577665278fe08fbaafe2239553f3c448e, ghc-8.1.20160720) reports: {{{ Acquire.hs:17:21: error: • Couldn't match expected type ‘t’ with actual type ‘(forall b1. b1 -> b1) -> IO b’ ‘t’ is a rigid type variable bound by the inferred type of g :: t at Acquire.hs:17:13-28 • In the pattern: Acquire g In a pattern binding: Acquire g = g' x In the expression: do { x <- f restore; let Acquire g = g' x; g restore } • Relevant bindings include g' :: a -> Acquire b (bound at Acquire.hs:15:19) (>>=) :: Acquire a -> (a -> Acquire b) -> Acquire b (bound at Acquire.hs:15:15) }}} This example is reduced from the `recourcet` package on Hackage, module `Data.Acquire.Internal`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 24 Oct '16

24 Oct '16

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: maurerl@… (added) Comment: Let's do (1); it's nearly ready! Akio, Luke (now in cc), can you work together on this? Luke has a pretty stable join-point branch which never destroys join points. Best just to build on that I think. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12756: ghci gives stg_ap_v_ret error
by GHC 24 Oct '16

24 Oct '16

#12756: ghci gives stg_ap_v_ret error --------------------------------------+---------------------------------- Reporter: ryanreich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- The following interaction with ghci occurs: {{{ Prelude> :l Test.hs [1 of 2] Compiling BigWord ( lib/BigWord.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, modules loaded: BigWord, Main. *Main> main <interactive>: internal error: stg_ap_v_ret (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} whereas the compiled file Test.hs executes without error. See the attached files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 24 Oct '16

24 Oct '16

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Regarding `wave4main`, the main problem seems to be destruction of a join point. The program contains an expression that looks like this: {{{ #!haskell runRW# (\ s -> letrec go s1 = let ... in (# s2, Array a b c #) in go s) }}} After a nested CPR transformation, it becomes: {{{#!haskell runRW# (\ s -> letrec $wgo s1 = let ... in (# s2, a, b, c #) in case $wgo s of (# s3, a', b', c' #) -> (# s3, Array a' b' c' #)) }}} destroying the join-point property of `go`. This is basically the same as what @nomeata found 2 years ago. I see two ways to move forward: 1. Wait for SequentCore to be implemented. 2. Have special cases for `runRW#` in the CPR analyzer and in the simplifier, as discussed in https://ghc.haskell.org/trac/ghc/ticket/10678#comment:10 I'm mildly interested in doing (2), but I don't think I fully understand the idea. In particular, the above comment mentions an example expression `case (runRW e) of BN# farr -> farr` that the simplifier would be able to transform. However, since `runRW#` returns an unboxed pair rather than a single boxed value, it seems that it would have to spot a much more complicated pattern to accomplish this transformation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12729: Unlifted newtypes via GADTSyntax
by GHC 23 Oct '16

23 Oct '16

#12729: Unlifted newtypes via GADTSyntax -------------------------------------+------------------------------------- Reporter: monoidal | 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: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC disallows to define a newtype of an unlifted type (`newtype A = A Int#`). However, this restriction is not enforced when the newtype is defined using GADT syntax: {{{ newtype A where A :: Int# -> A }}} For example, I can derive Show for A and on my machine `main = print (A 0#)` segfaults. Tested on GHC 8.0.1 and master. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12752: GHC should be able to warn on usafe CPP usage
by GHC 23 Oct '16

23 Oct '16

#12752: GHC should be able to warn on usafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GCC has a warning `-Wundef` that catches unsafe CPP usage like: {{{#!c #if variable_does_not_exist // something #endif }}} The GCC man page says about `-Wundef`: {{{ -Wundef Warn if an undefined identifier is evaluated in an "#if" directive. }}} Following GCC's lead, GHC should have a similar warning flag to detect and warn about this problem in Haskell code that uses CPP. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7