February 2015 - ghc-tickets

[GHC] #9223: Type equality makes type variable untouchable
by GHC 21 Jan '17

21 Jan '17

#9223: Type equality makes type variable untouchable -------------------------------------------+------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This doesn't look right: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} type family TF (m :: * -> *) run1 :: (forall m . Monad m => m a) -> a run1 = undefined run2 :: (forall m . (Monad m, TF m ~ ()) => m a) -> a run2 = undefined -- this works x1 = run1 (return ()) -- this fails x2 = run2 (return ()) {- Couldn't match expected type ‘a’ with actual type ‘()’ ‘a’ is untouchable inside the constraints (Monad m, TF m ~ ()) bound by a type expected by the context: (Monad m, TF m ~ ()) => m a at untouchable.hs:15:6-21 ‘a’ is a rigid type variable bound by the inferred type of x2 :: a at untouchable.hs:15:1 Relevant bindings include x2 :: a (bound at untouchable.hs:15:1) In the first argument of ‘return’, namely ‘()’ In the first argument of ‘run2’, namely ‘(return ())’ -} }}} I would expect x2 to type check just like x1 does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9137: A way to match RULES only for literals
by GHC 16 Jan '17

16 Jan '17

#9137: A way to match RULES only for literals ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- In `GHC/Enum` we have {{{ {-# RULES "enumDeltaToInteger1" [0] forall c n x . enumDeltaToIntegerFB c n x 1 = up_fb c n x 1 #-} -- This rule ensures that in the common case (delta = 1), we do not do the check here, -- and also that we have the chance to inline up_fb, which would allow the constructor to be -- inlined and good things to happen. -- We do not do it for Int this way because hand-tuned code already exists, and -- the special case varies more from the general case, due to the issue of overflows. }}} This rule would be useful for all literals, not just for `1`. I remember a discussion that such a rule would be more useful if we had a way to specify that, for example (random syntax). {-# RULES "enumDeltaToInteger1" [0] forall c n x d . isLiteral d => enumDeltaToIntegerFB c n x d = up_fb c n x d #-} I’m reporting this now to be able to link to it from #9136, where this feature might also help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10073: Idris REPL is pretty and we can too
by GHC 14 Jan '17

14 Jan '17

#10073: Idris REPL is pretty and we can too -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Manual for configuring colors in the Idris REPL: https://github.com/idris- lang/Idris-dev/wiki/Manual#colours Screenshot: http://i.imgur.com/rYHCI4T.png Particularly, I'd like to make type errors and warnings more visually distinct. I think little touches like this can go a long way to making it nice to work with Haskell code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10083: ghc: panic! (the 'impossible' happened)
by GHC 12 Jan '17

12 Jan '17

#10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I used hprotoc to generate some code for Google protocol buffers. The QueryValue.proto file is attached. You can install hprotoc tool using cabal. then use ''hprotoc QueryValue.proto'' to generate code. Then create a minimal cabal file. ''cabal init -m --is-library -n'' Then if you build it with '''optimization enabled''', the build will fail ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sEMq{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 59242 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #8761: Make pattern synonyms work with Template Haskell
by GHC 10 Jan '17

10 Jan '17

#8761: Make pattern synonyms work with Template Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Template Haskell has no support for pattern synonyms. This should be added. Specifically: * Create syntax in `Language.Haskell.TH.Syntax` and corresponding functions in `Language.Haskell.TH.Lib` * Support in !DsMeta for desugaring pattern synonym quotations. See `rep_bind`. * Support in Convert for splicing in pattern synonyms. * Support in !TcSplice for reifying pattern synonyms. See `reifyThing`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9748: Disambiguate IO actions in GHCi with :set +t
by GHC 06 Jan '17

06 Jan '17

#9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.2 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: -------------------------------------+------------------------------------- Currently GHCi's `:set +t` displays the same type for the following: {{{#!hs % ghci -ignore-dot-ghci GHCi, version 7.8.2: 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> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char Prelude> return 'a' :: IO Char 'a' it :: Char }}} A user at `#haskell-beginners` ran into a problem where they mistook an expression that defaulted to IO for a pure expression (`Id . even <$> pure 5`), `:set +t` was suggested but ended up showing the incorrect type: {{{#!hs ghci> Id . even <$> pure 5 Id False it :: Id Bool }}} This is bad for pedagogical reasons, it would be an improvement to display the following: {{{#!hs Prelude> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char <- return 'a' :: IO Char Prelude> return 'a' :: IO Char 'a' it :: Char <- return 'a' :: IO Char }}} mirroring existing syntax: {{{#!hs Prelude> :set -XScopedTypeVariables Prelude> a :: Char <- return 'a' :: IO Char a :: Char }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9248: Document -XHaskell98 and -XHaskell2010 in flag reference
by GHC 05 Jan '17

05 Jan '17

#9248: Document -XHaskell98 and -XHaskell2010 in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8107: need types to express constant argument for primop correctness
by GHC 21 Dec '16

21 Dec '16

#8107: need types to express constant argument for primop correctness ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- (not sure if this is a bug or a feature request, or a task, or a dialogue, filing as a bug for now) a number of compiler intrinsics that GHC has started to support (prefetch) and will come to support (concurrent memory operations a la http://ghc.haskell.org/trac/ghc/ticket/7883) require certain arguments to be statically fixed at compile time {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# -> Int# -> Addr# with llvm_only = True }}} consider the specification on the llvm side for prefetch http://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic {{{ Syntax:¶ declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>, i32 <cache type>) Overview: The ‘llvm.prefetch‘ intrinsic is a hint to the code generator to insert a prefetch instruction if supported; otherwise, it is a noop. Prefetches have no effect on the behavior of the program but can change its performance characteristics. Arguments: address is the address to be prefetched, rw is the specifier determining if the fetch should be for a read (0) or write (1), and locality is a temporal locality specifier ranging from (0) - no locality, to (3) - extremely local keep in cache. The cache type specifies whether the prefetch is performed on the data (1) or instruction (0) cache. The rw, locality and cache type arguments must be constant integers. }}} the punch line is that we're starting add primops that REALLY require certain arguments to be compile time constants to work correctly, otherwise there will by definition be compiler errors after the c-- phase when operations are passed along to the llvm backend and friends. (for the atomicity ops, i'll be looking into adding them to the native code gen, but the point being it will likely trigger an error at code gen time). a strawman approach would look like adding a type {{{ ReallyActuallyConstant :: * or unliftedtype -> * unliftedtype}}} roughly, then prefetch could have the type {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# ->ReallyActuallyConstant Int# -> Addr# with llvm_only = True }}} a way of emulating something like this functionality now, would be some template haskell that lets you lift a compile time constant of type t into the type ReallyActuallyConstant t, and is the only way to build a value of that type "ReallyActuallyConstant t". That said, that approach seems like a bad way of providing type safetype for making sure primops actually compile! Point being, some sort of way of nicely enforcing that a value needs to be available at compile time, that doesn't require doing abusing template haskell, is the idea i'm pointing at. Might also be useful for other things, but for now, i'm merely remarking on an invariant these primops have -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9509: No automatic specialization of inlinable imports in 7.8
by GHC 21 Dec '16

21 Dec '16

#9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- According to the GHC manual, any uses of an imported definition that is overloaded and INLINABLE will automatically cause a SPECIALIZE to be generated for those uses, if appropriate. However, this no longer appears to be the case in 7.8(.3). Here is a simple test case: {{{#!hs module A (foo) where import Data.IORef foo :: Ord a => a -> IO a foo x = newIORef x >>= readIORef >>= \y -> case compare x y of LT -> return x ; _ -> return y {-# INLINABLE foo #-} }}} {{{#!hs module Main (main) where import A main = foo (5 :: Int) >>= print }}} `foo` is constructed to be long enough that GHC 7.8.3 will elect to not inline it. When compiling with 7.6.3, the core contains the following: {{{ Main.$sfoo1 :: GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 55 30}] Main.$sfoo1 = \ (x_XkE :: GHC.Types.Int) (eta_B1 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.newMutVar# @ GHC.Types.Int @ GHC.Prim.RealWorld x_XkE eta_B1 of _ { (# ipv_amT, ipv1_amU #) -> case GHC.Prim.readMutVar# @ GHC.Prim.RealWorld @ GHC.Types.Int ipv1_amU ipv_amT of ds1_amJ { (# ipv2_Xn8, ipv3_Xna #) -> case x_XkE of wild_axu { GHC.Types.I# x#_axw -> case ipv3_Xna of _ { GHC.Types.I# y#_axA -> case GHC.Prim.<# x#_axw y#_axA of _ { GHC.Types.False -> ds1_amJ; GHC.Types.True -> (# ipv2_Xn8, wild_axu #) } } } } } Main.$sfoo :: GHC.Types.Int -> GHC.Types.IO GHC.Types.Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType LL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] Main.$sfoo = Main.$sfoo1 `cast` (<GHC.Types.Int> -> Sym <(GHC.Types.NTCo:IO <GHC.Types.Int>)> :: (GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)) ~# (GHC.Types.Int -> GHC.Types.IO GHC.Types.Int)) ... ------ Local rules for imported ids -------- "SPEC A.foo [GHC.Types.Int]" [ALWAYS] forall ($dOrd_sxj :: GHC.Classes.Ord GHC.Types.Int) A.foo @ GHC.Types.Int $dOrd_sxj = Main.$sfoo }}} However, in 7.8.3 and newer (I'm actually using 7.9.20140725 for this particular output, but 7.8.3 is similar), we see the following: {{{ Main.main1 :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GblId, Arity=1, Str=DmdType <L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 100 0}] Main.main1 = \ (s_aIb :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ((A.foo @ GHC.Types.Int GHC.Classes.$fOrdInt Main.main2) `cast` (GHC.Types.NTCo:IO[0] <GHC.Types.Int>_R :: GHC.Types.IO GHC.Types.Int ~R# (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)))) s_aIb of _ [Occ=Dead] { (# ipv_aIe, ipv1_aIf #) -> GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout (GHC.Show.$fShowInt_$cshow ipv1_aIf) GHC.Types.True ipv_aIe } }}} There is no local rules section in 7.8.3. Putting a manual SPECIALIZE pragma in the main module generates comparable code to 7.6.3, so it does not appear to be a failure at that level. Rather, GHC seems to just not be generating the SPECIALIZE equivalent. Presumably this is a regression, but even if not, the manual should be revised. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9509> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots
by GHC 19 Dec '16

19 Dec '16

#10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: | Owner: scpmw thoughtpolice | Status: new Type: bug | Milestone: 7.10.1 Priority: high | Version: 7.10.1-rc1 Component: Profiling | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9961 Blocking: | Differential Revisions: Phab:D616 | -------------------------------------+------------------------------------- Split off from #9961 - the profiling results while debugging erroneously reported that most cost centre profiles were a result of `lintAnnots`, as opposed to `CSE`. This is a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21