- ghc-tickets - Haskell.org

[GHC] #10662: GHC warning shows technical summary of AST instead of the user's code
by GHC 17 Dec '15

17 Dec '15

#10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I got a warning for some code I wrote; {{{#!hs forkIO (....) }}} Naturally GHC warns me that I'm throwing away the result, and should write like this; {{{#!hs _ <- forkIO (...) }}} However, the warning is expressed in a somewhat confusing way, not sure this is intentional. {{{ examples/route_guide_client.hs:84:5: Warning: A do-notation statement discarded a result of type ‘ThreadId’ Suppress this warning by saying ‘_ <- ($) forkIO let AbsBinds [] [] {Exports: [go <= go <>] Exported types: go :: [L.ByteString] -> IO () [LclId, Str=DmdType] Binds: go acc = ...} in go []’ or by using the flag -fno-warn-unused-do-bind }}} I find it confusing that the warning mentions AbsBinds, exports and types. I'd expect a snippet of my code in the warning. However, doesn't look like this is a (recent) regression. The same happens GHC 7.8.4 and 7.10.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11232: Panic whilst compiling syb due to OptCoercion
by GHC 17 Dec '15

17 Dec '15

#11232: Panic whilst compiling syb due to OptCoercion -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is the minimised test case with most definitions inlined. {{{ module Data.Generics.Aliases where import Control.Monad import Data.Data mkMp :: ( MonadPlus m , Typeable a , Typeable b ) => (b -> m b) -> a -> m a mkMp ext = unM (maybe (M (const mzero)) id (gcast (M ext))) newtype M m x = M { unM :: x -> m x } }}} Panics with `-O2` as follows, {{{ ~/Documents/haskell/syb-0.6:ghc-7.11.20151214 Aliases.hs -O2 [1 of 1] Compiling Data.Generics.Aliases ( Aliases.hs, Aliases.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.11.20151214 for x86_64-apple-darwin): ASSERT failed! file compiler/types/OptCoercion.hs, line 234 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11235: Haddock shows no class members
by GHC 17 Dec '15

17 Dec '15

#11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At least since Haddock commit 0fc8cfd532f5dfd12b5504f44a2b3c9fb659cd87 on the `ghc-head` branch Haddock's HTML output has shown no class members. I'll need to work out why this is before the release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11215: Line endings in quasiquotations are not normalised
by GHC 17 Dec '15

17 Dec '15

#11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following [http://hackage.haskell.org/package/raw-strings-qq simple quasiquoter]: {{{#!hs foo = QuasiQuoter { quoteExp = return . LitE . StringL [...] }}} When used like this: {{{#!hs bar :: String bar = [foo|FOO BAR BAZ|] }}} the string `bar` will contain either LF or CRLF line endings depending on which convention is used in the file. This is consistent with documentation, if a bit surprising. However, the problem is that version control systems (e.g. Git) usually store text files using Unix line endings, but allow checking them out in a platform- specific format. So this behaviour gives rise to subtle semantics changes in the compiled program that depend on the user's VCS settings. Therefore IMO it makes sense to always normalise CRLF to LF in quasiquotations. Originally reported [https://github.com/23Skidoo/raw-strings-qq/issues/1 here], a test case can be found [https://github.com/23Skidoo/raw-strings- qq/blob/master/test/Test.hs here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10034: Regression in mapM_ performance
by GHC 17 Dec '15

17 Dec '15

#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.10.1-rc2 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D632 | -------------------------------------+------------------------------------- The current `mapM_` is sometimes worse than the version in 7.8.3. This can be fixed easily by eta-expansion, matching `mapM`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11067: Spurious superclass cycle error with type equalities
by GHC 17 Dec '15

17 Dec '15

#11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Some of us today had an idea how to repair Edward Kmett's regrettably unsound `Data.Constraint.Forall` module. The method works fine in some cases, but seems to occasionally trigger a spurious superclass cycle error. In the cases I've seen so far, it seems to happen when a class is defined with a `Forall` superclass, where that `Forall` itself has as parameter another class, that itself has a type equality superclass. Example file (a bit larger than necessary to show how a similar example without a type equality ''doesn't'' give an error): {{{#!haskell {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import Data.Monoid import GHC.Exts (Constraint) type family Skolem (p :: k -> Constraint) :: k type family SkolemF (p :: k2 -> Constraint) (f :: k1 -> k2) :: k1 -- | A quantified constraint type Forall (p :: k -> Constraint) = p (Skolem p) type ForallF (p :: k2 -> Constraint) (f :: k1 -> k2) = p (f (SkolemF p f)) -- These work class ForallF Monoid t => Monoid1 t instance ForallF Monoid t => Monoid1 t class ForallF Monoid1 t => Monoid2 t instance ForallF Monoid1 t => Monoid2 t -- Changing f a ~ g a to, (Ord (f a), Ord (g a)), say, removes the error class (f a ~ g a) => H f g a instance (f a ~ g a) => H f g a -- This one gives a superclass cycle error. class Forall (H f g) => H1 f g instance Forall (H f g) => H1 f g }}} And the resulting error: {{{ Test.hs:31:1: Cycle in class declaration (via superclasses): H1 -> Forall -> H -> H In the class declaration for ‘H1’ Test.hs:31:1: Cycle in class declaration (via superclasses): H1 -> Forall -> H -> H In the class declaration for ‘H1’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11237: Type synonyms are not expanded in the data type declaration return kind
by GHC 17 Dec '15

17 Dec '15

#11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | 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: -------------------------------------+------------------------------------- I was playing around with the cool new `-XTypeInType` stuff when I encountered the following issue: {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs #-} module TypeInTypeBug where import qualified Data.Kind -- This works, using Data.Kind.Type as return kind --------------vvvvvvvvvvvvvv data Works :: Data.Kind.Type where WorksConstr :: Works type Set = Data.Kind.Type -- This doesn't work, using a type synonym for Data.Kind.Type as return kind ---------------vvv data Doesnt :: Set where DoesntConstr :: Doesnt }}} {{{ TypeInTypeBug.hs:17:1: error: • Kind signature on data type declaration has non-* return kind Set • In the data declaration for ‘Doesnt’ }}} I suppose type synonyms should be expanded in the return kind of a data type declaration before checking it is `*`. I also think the error message is not totally correct, take the following '''valid''' data declaration: {{{#!hs data Foo :: Bool -> Data.Kind.Type where Tru :: Foo True Fal :: Foo False }}} The return kind of the data declaration is actually `Bool -> Data.Kind.Type` (or `Bool -> *`), which is not `*`. I assume the error message is talking about the return kind (`*`) of the return kind (`Bool -> *`) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4945: Another SpecConstr infelicity
by GHC 17 Dec '15

17 Dec '15

#4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T4945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: high => normal Comment: To summarise: test T4945 is failing. Lowering priority, because it is just some (-O2) runtime performance issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4945#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs
by GHC 16 Dec '15

16 Dec '15

#781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.5 (Linker) | Keywords: Resolution: | getEnvironment Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: | getEnvironment01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: high => normal Comment: Lowering priority, because this is only a problem when GHC is built with `DYNAMIC_GHC_PROGRAMS=NO` (the default is `YES`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/781#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9276: audit ghc floating point support for IEEE (non)compliance
by GHC 16 Dec '15

16 Dec '15

#9276: 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/9276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10