June 2016 - ghc-tickets

[GHC] #11549: Add -fshow-runtime-rep
by GHC 29 Jul '18

29 Jul '18

#11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- As discussed in several interwoven threads ([https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html original], [https://mail.haskell.org/pipermail/haskell- cafe/2016-February/122914.html café]), it has been suggested to add a flag `-fshow-runtime-rep`. Without this flag enabled, the pretty printer will instantiate any `RuntimeRep` type parameters to `PtrRep Lifted`. This has the effect of changing {{{ ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b }}} to {{{ ($) :: (a -> b) -> a -> b }}} under the default GHCi settings. Note that `Levity` becomes `RuntimeRep` after #11471 is complete. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11549> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10184: Coercible solver incomplete with recursive newtypes
by GHC 29 Jul '18

29 Jul '18

#10184: Coercible solver incomplete with recursive newtypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.10.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following module fails to compile due to infinite recursion: {{{ import Data.Coerce newtype Bar a = Bar (Either a (Bar a)) newtype Age = MkAge Int x :: Bar Age x = coerce (Bar (Left (5 :: Int))) }}} It tries to coerce `Bar Int` to `Bar Age`. This is clearly doable, via tyconapp decomposition. But we don't find it. Before worrying too much about it, though, we'll wait for a real example. Do speak up if this problem is ruining your day! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9936: Data.Fixed truncates 5.17 to 5.16
by GHC 28 Jul '18

28 Jul '18

#9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `(realToFrac (5.17 :: Double) :: Centi) == 5.16` is true -- it should be false. The offender seems to be the assumption in `fromRational`: `fromRational r = withResolution (\res -> MkFixed (floor (r * (toRational res))))` Uses `floor` assuming that the underlying floating point value is stored purely and not as 0.999999 or similar -- switching it to `round` fixes this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9936> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised
by GHC 28 Jul '18

28 Jul '18

#10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: recursion- | Owner: ninja | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: panic | Operating System: Linux impossible linker initialized | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- When trying to build the CUDA accelerate backend I get the following "complier panic": {{{ me@box:~/accelerate-cuda-0.15.0.0$ cabal build Building accelerate-cuda-0.15.0.0... Preprocessing library accelerate-cuda-0.15.0.0... Data/Array/Accelerate/CUDA/CodeGen/Base.hs:5:14: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS [ 7 of 33] Compiling Data.Array.Accelerate.CUDA.CodeGen.Type ( Data/Array/Accelerate/CUDA/CodeGen/Type.hs, dist/build/Data/Array/Accelerate/CUDA/CodeGen/Type.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [ 9 of 33] Compiling Data.Array.Accelerate.CUDA.Debug ( Data/Array/Accelerate/CUDA/Debug.hs, dist/build/Data/Array/Accelerate/CUDA/Debug.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [10 of 33] Compiling Data.Array.Accelerate.CUDA.Analysis.Launch ( Data/Array/Accelerate/CUDA/Analysis/Launch.hs, dist/build/Data/Array/Accelerate/CUDA/Analysis/Launch.o ) <no location info>: <command line>: can't load .so/.DLL for: /home/me/.cabal/lib/x86_64 -linux-ghc-7.10.2/cuda-0.6.7.0-EMlxEWvymgZGXnLSaVKypt/libHScuda-0.6.7.0 -EMlxEWvymgZGXnLSaVKypt-ghc7.10.2.so (libcudart.so.7.5: cannot open shared object file: No such file or directory) }}} This is the accelerate cuda package version 0.15.0.0: https://hackage.haskell.org/package/accelerate-cuda I changed the constraints from base==4.7.* to base==4.8.* to allow for compilation with GHC 7.10.2. After installing the dependencies through cabal and attempting to manually build the package manuall with cabal build I get the above mentioned compiler panics. GHC instructed me to report the issue as a bug (defect) so I did. I'd like to get this library to build with the newest version of GHC so please let me know how to proceed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code
by GHC 24 Jul '18

24 Jul '18

#8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 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: | -------------------------------------+------------------------------------- Consider the following: {{{ {-# LANGUAGE StandaloneDeriving, GADTs, FlexibleInstances #-} module StandaloneDerivingGADT where data T a where MkT1 :: T Int MkT2 :: (Bool -> Bool) -> T Bool deriving instance Show (T Int) }}} This gives the error: {{{ StandaloneDerivingGADT.hs:9:1: Couldn't match type ‛Int’ with ‛Bool’ Inaccessible code in a pattern with constructor MkT2 :: (Bool -> Bool) -> T Bool, in an equation for ‛showsPrec’ In the pattern: MkT2 b1 In an equation for ‛showsPrec’: showsPrec a (MkT2 b1) = showParen ((a >= 11)) ((.) (showString "MkT2 ") (showsPrec 11 b1)) When typechecking the code for ‛showsPrec’ in a standalone derived instance for ‛Show (T Int)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‛Show (T Int)’ }}} The derived instance declaration matches on all the constructors, even if they cannot possibly match. It should omit obviously inaccessible constructors so that this example is accepted. For reference, the derived code is: {{{ instance GHC.Show.Show (StandaloneDerivingGADT.T GHC.Types.Int) where GHC.Show.showsPrec _ StandaloneDerivingGADT.MkT1 = GHC.Show.showString "MkT1" GHC.Show.showsPrec a_aij (StandaloneDerivingGADT.MkT2 b1_aik) = GHC.Show.showParen ((a_aij GHC.Classes.>= 11)) ((GHC.Base..) (GHC.Show.showString "MkT2 ") (GHC.Show.showsPrec 11 b1_aik)) GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0) }}} The same problem applies to other derivable classes (e.g. `Eq`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8740: Code conditionally compiles
by GHC 24 Jul '18

24 Jul '18

#8740: Code conditionally compiles ----------------------------+---------------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} data Abstract data Reified data Player data Elect p a where ElectRefAsTypeOf :: Int -> Elect Abstract a -> Elect Abstract a ElectHandle :: a -> Elect Reified a Controller :: Elect Abstract Player Owner :: Elect Abstract Player You :: Elect Abstract Player deriving instance (Eq a) => Eq (Elect p a) deriving instance (Ord a) => Ord (Elect p a) }}} As is, the above code fails to compile. But if I move `ElectRefAsTypeOf` to be the last constructor for the GADT, the code does compile. If I remove one of the `Elect Abstract Player` constructors, the code still won't compile even if the `ElectRefAsTypeOf` is moved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9599: app runs 10 times faster when compiled with profilling information than without it
by GHC 21 Jul '18

21 Jul '18

#9599: app runs 10 times faster when compiled with profilling information than without it -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello, I've found interesting application code which when compiled with {{{ -O2 -threaded --make }}} runs 10 times slower than the same code compiled with {{{ -O2 -threaded --make -prof -auto-all -caf-all -fforce-recomp }}} the application is compiled by GHC 7.8.2 on i386-solaris2 platform. The profiling application is then run as normal application, i.e. without +RTS -p. The application itself is my crude beginner Haskell code which takes Wikipedia dump (XML file) and tries wiki pages from there import into XWiki using REST API. It uses Data.Text package for lazy load of Wikipedia data, whole logic of selection of page/title/content is done on Data.Text and later saved into XPage which is using ByteString. The application also uses Simon Marlow's Async/async/wait code which is copied from Simon Marlow's Parallel and Concurrent Programming in Haskell http://chimera.labs.oreilly.com/books/1230000000929 App attached. My question is, what to do with it to help finding the issue? E.g. I assume it's issue when profiling app is that much faster than common optimized app. For your information, optimized app takes 9m50s to upload 1000 pages while profiled optimized app takes only 50s to upload the same amount of pages on my equipped with E5-2620 (2 GHz 6 core/12 threads xeon) Also the difference in time is that big that it's not caused by a noise in import of pages on XWiki side. I've tested several times of course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8581: Add support for explicitly-bidirectional pattern synonyms
by GHC 12 Jul '18

12 Jul '18

#8581: Add support for explicitly-bidirectional pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Some patterns cannot, by themselves, be turned over into an expression, so they have to be defined as unidirectional. Maybe the most trivial example would be {{{ pattern P -> _ }}} Sometimes, however, it would be desirable to give an explicit way of turning these pattern synonyms into expressions. The PatternSynonyms wiki page has this example: {{{ import qualified Data.Sequence as Seq pattern Empty -> (Seq.viewl -> Seq.EmptyL) pattern x :< xs -> (Seq.viewl -> x Seq.:< xs) pattern xs :> x -> (Seq.viewr -> xs Seq.:> x) }}} It would make a ton of sense to be able to use this cons/snoc notation as "constructors" for `Seq`s. The proposed syntax for this {{{ pattern x :< xs -> (Seq.viewl -> x Seq.:< xs) where x :< xs = x Seq.<| xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #12050: Allow haddock comments on non-record types
by GHC 10 Jul '18

10 Jul '18

#12050: Allow haddock comments on non-record types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | 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: -------------------------------------+------------------------------------- There are a variety of cases I have found myself wanting to place haddock documentation on fields of non-record data types rather often in the past. The syntax for this might look like, {{{#!hs data Foo = Foo -- ^ A foo Int -- ^ how big is the foo? String -- ^ the name of the foo }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12050> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8822: Allow -- ^ Haddock syntax on record constructors
by GHC 10 Jul '18

10 Jul '18

#8822: Allow -- ^ Haddock syntax on record constructors -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | 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: | -------------------------------------+------------------------------------- Original ticket is on Haddock Trac [http://trac.haskell.org/haddock/ticket/144 here] which I'm opening here as it requires lexer/parser changes. The idea is that given something like {{{ -- | A tree with labeled internal nodes data Tree = Empty -- ^ Leaf | Branch -- ^ Internal node { label :: a -- ^ Node label , subtrees :: [Tree] -- ^ List of subtrees } }}} we'd like it to parse as the user would expect instead of failing. We're currently forced to do something like {{{ -- | A tree with labeled internal nodes data Tree = Empty -- ^ Leaf | -- | Internal node Branch { label :: a -- ^ Node label , subtrees :: [Tree] -- ^ List of subtrees } }}} which is quite ugly. I can't think of a reason why the first form wouldn't be allowed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8822> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8