- ghc-tickets - Haskell.org

[GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 03 May '13

03 May '13

#7854: Constrained method type accepted in Haskell 98 mode -----------------------------+---------------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- If I understand [http://www.haskell.org/ghc/docs/7.6.2/html/users_guide /type-class-extensions.html#class-method-types this paragraph] of the GHC manual correctly, the following code should be rejected in Haskell 98 mode: {{{ {-# LANGUAGE Haskell98 #-} module Main where class Compare a where comp :: Eq a => a -> a -> Bool }}} However, it compiles fine for me both with 7.4.2 and 7.6.1. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7865: SpecConstr duplicating computations
by GHC 03 May '13

03 May '13

#7865: SpecConstr duplicating computations ------------------------------------+--------------------------------------- Reporter: amosrobinson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: | Keywords: SpecConstr Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- In some (very rare) cases, SpecConstr can actually duplicate let bindings. When SpecConstr sees something like {{{ let tuple = (let x = expensive in x, simple) case tuple of (a,b) -> a + a }}} it records the value of tuple, and replaces the case with {{{ (let x = expensive in x) + (let x = expensive in x) }}} Usually we wouldn't notice this, because the Simplifier would let-float expensive out of the tuple before SpecConstr runs. In some cases though, the tuple constructor will only be exposed after specialisation happens. To test, compile TSpecConstr_DoubleInline with {{{ ghc TSpecConstr_DoubleInline.hs -O2 -fspec-constr -dverbose-core2core -fforce-recomp -dppr-case-as-let -dsuppress-all | less }}} and search for the SpecConstr pass. The first specialisation is {{{ $srecursive_sf3 $srecursive_sf3 = \ sc_seR sc_seS sc_seT sc_seU -> let { a'_sep a'_sep = (let { I# x_adP ~ _ <- expensive sc_seR } in I# (*# x_adP 2), sc_seR) } in let { ds_seq ds_seq = recursive (: sc_seR (: sc_seR (: sc_seS sc_seT))) (sc_seR, let { I# x_adP ~ _ <- expensive sc_seR } in I# (*# x_adP 2)) } in (let { (p_XdA, q_Xdu) ~ _ <- ds_seq } in let { I# x_ae7 ~ _ <- p_XdA } in let { I# y_aeb ~ _ <- let { I# x_adP ~ _ <- expensive sc_seR } in I# (*# x_adP 2) } in I# (+# x_ae7 y_aeb), let { (p_adg, q_XdA) ~ _ <- ds_seq } in let { I# x_ae7 ~ _ <- q_XdA } in let { I# y_aeb ~ _ <- sc_seR } in I# (+# x_ae7 y_aeb)) }}} With three calls to expensive. If you look at the -ddump-prep, one of the calls is simplified out, but there is still one too many at the end. This is happening on at least 7.4.1 and head. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #2648: Report out of date interface files robustly
by GHC 03 May '13

03 May '13

#2648: Report out of date interface files robustly ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): As Ian says, I think we are stalled on fixing this until we have a test case. The scenario I wrote up at the start is a bit contrived, and I'm far from certain that it's what people are tripping over. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2648#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous
by GHC 03 May '13

03 May '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): Any time there's a catch/rethrow inside an `unsafePerformIO` we'll have this problem. So in the specific case of the GHC API it would help to know where this is happening, and whether we can avoid it. One way I can think of that might help in general is to have a special kind of catch that doesn't catch asynchronous exceptions. So in cases like your example, `catchIOError` would use the special sync-only catch internally, and would ignore the async exception. However, this unfortunately doesn't help with `bracket` and `finally`, which need to do some cleanup in the exception handler, and I suspect these are more common than `catch`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5902#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7862: Could not deduce (A) from the context (A, ...)
by GHC 03 May '13

03 May '13

#7862: Could not deduce (A) from the context (A, ...) --------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following code doesn't compile and produces a strange error: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} module Numeric.AD.Internal.Tower () where type family Scalar t newtype Tower s a = Tower [a] type instance Scalar (Tower s a) = a class (Num (Scalar t), Num t) => Mode t where (<+>) :: t -> t -> t instance (Num a) => Mode (Tower s a) where Tower as <+> _ = undefined where _ = (Tower as) <+> (Tower as) instance Num a => Num (Tower s a) where }}} {{{ src/Numeric/AD/Internal/Tower.hs:17:24: Could not deduce (Num (Scalar (Tower s a))) arising from a use of `<+>' from the context (Num (Scalar (Tower s a)), Num (Tower s a), Num a) bound by the instance declaration at src/Numeric/AD/Internal/Tower.hs:14:10-36 Possible fix: add an instance declaration for (Num (Scalar (Tower s a))) In the expression: (Tower as) <+> (Tower as) In a pattern binding: _ = (Tower as) <+> (Tower as) In an equation for `<+>': (Tower as) <+> _ = undefined where _ = (Tower as) <+> (Tower as) }}} Furthermore, Removing the {{{Num (Scalar t)}}} constraint from the {{{Mode}}} class produces a different strange error: {{{ src/Numeric/AD/Internal/Tower.hs:17:24: Overlapping instances for Num (Tower s0 a) arising from a use of `<+>' Matching givens (or their superclasses): (Num (Tower s a)) bound by the instance declaration at src/Numeric/AD/Internal/Tower.hs:14:10-36 Matching instances: instance Num a => Num (Tower s a) -- Defined at src/Numeric/AD/Internal/Tower.hs:19:10 (The choice depends on the instantiation of `a, s0') In the expression: (Tower as) <+> (Tower as) In a pattern binding: _ = (Tower as) <+> (Tower as) In an equation for `<+>': (Tower as) <+> _ = undefined where _ = (Tower as) <+> (Tower as) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7873: A poly-kinded newtype existential crisis
by GHC 03 May '13

03 May '13

#7873: A poly-kinded newtype existential crisis --------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following code worked on older GHCs and on other compilers clear back to Hugs, but based on reports I'm getting from a half-dozen users appears to broken on GHC 7.6.1+ and in GHC HEAD. {{{ class Reifies s a | s -> a where reflect :: proxy s -> a data Proxy a = Proxy newtype Magic a r = Magic (forall s. Reifies s a => Proxy s -> r) }}} {{{ fast/Data/Reflection.hs:92:21: A newtype constructor cannot have an existential context, but `Magic' does In the definition of data constructor `Magic' }}} There doesn't appear to be anything existential going on there, but that said, this issue does only occur when PolyKinds are turned on, so perhaps the issue is with the desugaring into PolyKinds? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7884: Cannot build hedgewars with new haskell 7.6
by GHC 03 May '13

03 May '13

#7884: Cannot build hedgewars with new haskell 7.6 -------------------------------+-------------------------------------------- Reporter: LocutusOfBorg | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: regression Os: Linux | Architecture: arm Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Hi All, I post here since this bug *CAN* be a regression between haskell 7.4 and 7.6. Please look at this log https://buildd.debian.org/status/fetch.php?pkg=hedgewars&arch=armhf&ver=0.9… Everything is fine with haskell 7.4 and this one https://launchpadlibrarian.net/138989726/buildlog_ubuntu-saucy- armhf.hedgewars_0.9.18-0.3_FAILEDTOBUILD.txt.gz this seems to be an uncorrent link with the new haskell -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7884> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7881: Warning for pointless ranges like [5..2]
by GHC 03 May '13

03 May '13

#7881: Warning for pointless ranges like [5..2] -----------------------------+---------------------------------------------- Reporter: mpe | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: beginner,warning Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Haskell beginners sometimes tend to write ranges like [3..1] or [5..2] and assume that the result will be [3,2,1] or [5,4,3,2]. This is not the case of course. I suggest that literals like [5..2] generate a warning at compile time, analogous to: "Foo.hs:32: Warning: Literal list [5..2] evaluates to [] because 5 > 2 and the default step size is +1. Replace the literal with the empty list or with [5,4..2] to suppress this warning." In my opinion this should only be a compile time warning, not a runtime warning. If a > 3 and b is < 3 and you write [a..b] the result is still [], but that mistake can only be caught at runtime, and requires an additional run-time check. In some cases it may even be the desired behaviour to let [a..b] evaluate to [] if a>b. On the other hand, a literal expression like [5..2] is most likely an error, because if the user would expect [5..2] to evaluate to [], he would simply write []. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7875: Unhelpful IncoherentInstances suggestion with FunctionalDependencies
by GHC 03 May '13

03 May '13

#7875: Unhelpful IncoherentInstances suggestion with FunctionalDependencies -----------------------------+---------------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider the following program (simplified from http://hpaste.org/86928) {{{ {-# LANGUAGE FlexibleContexts , FlexibleInstances , FunctionalDependencies , MultiParamTypeClasses , KindSignatures , UndecidableInstances #-} class Het a b | a -> b where het :: m (f c) -> a -> m b class GHet (a :: * -> *) (b :: * -> *) | a -> b instance GHet (K a) (K [a]) instance Het a b => GHet (K a) (K b) data A a = A (A a) data K x a = K x instance Het (A a) (A [a]) where het = het1 het1 :: (GHet (K a) (K b)) => m (f c) -> a -> m b het1 = undefined }}} In HEAD, it gives rise to the following error: {{{ Overlapping instances for GHet (K (A a)) (K (A [a])) arising from a use of ‛het1’ Matching instances: instance Het a b => GHet (K a) (K b) -- Defined at Bug.hs:14:10 There exists a (perhaps superclass) match: (The choice depends on the instantiation of ‛a’ To pick the first instance above, use -XIncoherentInstances when compiling the other instance declarations) In the expression: het1 In an equation for ‛het’: het = het1 In the instance declaration for ‛Het (A a) (A [a])’ }}} It's already strange that it says multiple instances match, but it only lists one. Furthermore, enabling `-XIncoherentInstances`, as suggested, does not change the error message. #7150 and #7171 might be related. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7875> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7872: :info does not display "forall" for a synonym
by GHC 03 May '13

03 May '13

#7872: :info does not display "forall" for a synonym ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- Define: {{{ data A = A (forall a. a) type B = forall a. a }}} and in ghci we see: {{{ Prelude> :i A data A = A (forall a. a) -- OK Prelude> :i B type B = a -- "forall" missing }}} This is a minor issue, but since "type B = a" is not valid Haskell I'm reporting it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2