December 2017 - ghc-tickets

[GHC] #14578: Incorrect parenthesization of types in -ddump-deriv
by GHC 13 Jan '18

13 Jan '18

#14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this program on GHC 8.2 or later: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Control.Applicative import Data.Functor.Compose import Data.Semigroup newtype App f a = MkApp (f a) deriving (Functor, Applicative) instance (Applicative f, Semigroup a) => Semigroup (App f a) where (<>) = liftA2 (<>) newtype Wat f g a = MkWat (App (Compose f g) a) deriving Semigroup }}} Will result in some incorrectly pretty-printed types in the `-ddump-deriv` output: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs -dsuppress-uniques GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: <elided for brevity> instance (Data.Semigroup.Semigroup a, GHC.Base.Applicative g, GHC.Base.Applicative f) => Data.Semigroup.Semigroup (Bug.Wat f g a) where (Data.Semigroup.<>) = GHC.Prim.coerce @(Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(Bug.Wat f g a -> Bug.Wat f g a -> Bug.Wat f g a) (Data.Semigroup.<>) Data.Semigroup.sconcat = GHC.Prim.coerce @(Data.List.NonEmpty.NonEmpty Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(Data.List.NonEmpty.NonEmpty Bug.Wat f g a -> Bug.Wat f g a) Data.Semigroup.sconcat Data.Semigroup.stimes = GHC.Prim.coerce @(forall (b :: TYPE GHC.Types.LiftedRep). GHC.Real.Integral b => b -> Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(forall (b :: TYPE GHC.Types.LiftedRep). GHC.Real.Integral b => b -> Bug.Wat f g a -> Bug.Wat f g a) Data.Semigroup.stimes }}} Notice that is shows `Bug.App Data.Functor.Compose.Compose f g a`, which is wrong. It should be `Bug.App (Data.Functor.Compose.Compose f g) a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14182: Allow full control over dyn lib names
by GHC 12 Jan '18

12 Jan '18

#14182: Allow full control over dyn lib names -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.2.1 system | 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: -------------------------------------+------------------------------------- This is related to: * GHC ticket #11587 * Cabal issue https://github.com/haskell/cabal/issues/4263 * Cabal PR https://github.com/haskell/cabal/pull/4656 * Cabal PR https://github.com/haskell/cabal/pull/4426 Currently GHC hard codes the naming convention for shared/dynamic libraries. For example: For `hs-libraries: HScpu-0.1.2-b25995` in the package registration, on ELF GHC uses the name `libHScpu-0.1.2-b2599-ghc8.0.1.so` (and .dynlib on OSX). This naming convention is based on an old assumption that shared libraries would go in a shared `$libdir`, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version. This assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique. The obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information. We would of course keep the remaining necessary naming convention is the `lib` prefix and `.so`/`.dynlib`/`.dll` suffix, which is the same convention used by the system linker for `-lfoo` vs `libfoo.so`. **So specifically:** * Add a new `dynamic-hs-libraries` (to go along with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-library-dirs`. * When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing `-ghc8.0.1` convention is used. While we are at it, we should do the same for the `extra-libraries` and add a `dynamic-extra-libraries`. Note that there is an existing `extra- ghci-libraries` which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example, `pkg-config` makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14378: Unreasonably high memory use when compiling with profiling and -O2/-O2
by GHC 09 Jan '18

09 Jan '18

#14378: Unreasonably high memory use when compiling with profiling and -O2/-O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Based on [https://github.com/Daniel-Diaz/matrix/issues/43] I tried that myself. * Without profiling: <10 sec, <110M Residency * Profiling and -O: 90sec, 1.5GB Residency * Profiling and -O2: Killed it after 4 Minutes and it started swapping on a 16GB Ram machine. The invocation was: ghc Matrix.hs -prof -fprof-auto -c -fforce-recomp -O -v -fprof-auto-exported -caf-all -auto-all -fstatic-argument- transformation Numbers above from 8.0.2. 8.2.1 improved to slightly worse than -O1 with ~95 sec and ~2.5GB ram usage. Still seems like a bug though. I haven't tried HEAD yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14042: Data type with type family in return kind spuriously rejected
by GHC 08 Jan '18

08 Jan '18

#14042: Data type with type family in return kind spuriously rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This typechecks: {{{#!hs {-# LANGUAGE TypeInType #-} import Data.Kind type Id (a :: Type) = a data Foo :: Id Type }}} But changing the type synonym to a type family causes it to fail: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind type family Id (a :: Type) :: Type where Id a = a data Foo :: Id Type }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:9:1: error: • Kind signature on data type declaration has non-* return kind Id * • In the data declaration for ‘Foo’ | 9 | data Foo :: Id Type | ^^^^^^^^ }}} That error message is wrong, since `Id * = *`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10245: panic in new integer switch logic with "out-of-range" literals
by GHC 08 Jan '18

08 Jan '18

#10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this module {{{ module D (f) where f :: Int -> String f n = case n of 0x8000000000000000 -> "yes" _ -> "no" }}} crashes with the error {{{ [1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o ) ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20150403 for x86_64-unknown-linux): Map.findMin: empty map has no minimal element }}} The constant does not have to be exactly `0x8000000000000000`, everything I tested from there up to `0xffffffffffffffff` yields the same crash. Also occurs with `Word` and negative literals. The bug seems to be tied to the target's word size somehow, though: a 64-bit compiler does not panic on `Int32` and `0x80000000`, but a 32-bit compiler does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #14592: Totality checking
by GHC 05 Jan '18

05 Jan '18

#14592: Totality checking -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Example of that is Idris totality checking (http://docs.idris- lang.org/en/latest/tutorial/theorems.html#sect-totality) This feature could be started as a very specific types of pure functions which could be found to be total for sure and improve it in time. I'm putting a ticket for discussion here, because I didn't find any ticket related to that in GHC Trac. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14507: Core Lint error with Type.Reflection and pattern synonyms
by GHC 05 Jan '18

05 Jan '18

#14507: Core Lint error with Type.Reflection and pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language PatternSynonyms, ViewPatterns, GADTs, ConstraintKinds, RankNTypes, KindSignatures, PolyKinds, ScopedTypeVariables, DataKinds, TypeInType, TypeOperators, TypeApplications, TypeFamilies, TypeFamilyDependencies #-} import Type.Reflection import Prelude import Data.Kind data Dict c where Dict :: c => Dict c data N = O | S N foo :: forall (kind::k') (a::k). TypeRep kind -> TypeRep a -> Maybe (kind :~~: k, TypeRep a) foo krep rep = do HRefl <- eqTypeRep krep (typeRepKind rep) pure (HRefl, rep) pattern Bloop' :: forall k' (a::k). Typeable k' => k':~~:k -> TypeRep (a::k) -> TypeRep (a::k) pattern Bloop' hrefl rep <- (foo (typeRep @k') -> Just (hrefl, rep)) where Bloop' HRefl rep = rep type family SING = (res :: k -> Type) | res -> k where -- Core Lint error disappears with this line: SING = (TypeRep :: N -> Type) pattern RepN :: forall (a::kk). Typeable a => N~kk => SING a -> TypeRep (a::kk) pattern RepN tr <- Bloop' (HRefl::N:~~:kk) (tr :: TypeRep (a::N)) where RepN tr = tr asTypeable :: TypeRep a -> Dict (Typeable a) asTypeable rep = withTypeable rep Dict pattern TypeRep :: () => Typeable a => TypeRep a pattern TypeRep <- (asTypeable -> Dict) where TypeRep = typeRep -- error pattern SO = RepN TypeRep }}} triggers “Core Lint errors” on 8.2.1, 8.3.20170920 when run with `ghci -ignore-dot-ghci -dcore-lint`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14608: Different GHCi error messages for similar scenarios
by GHC 05 Jan '18

05 Jan '18

#14608: Different GHCi error messages for similar scenarios -------------------------------------+------------------------------------- Reporter: mb64 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the following code: {{{#!hs {-# LANGUAGE UnboxedTuples #-} module Test where data UnboxedTupleData = MkUTD (# (),() #) doThings :: UnboxedTupleData -> () doThings (MkUTD t) = () }}} This is accepted and compiled with a simple `ghc --make Test.hs`. However, with `ghci Test.hs`, you get an ugly error message: {{{#!hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): bcIdPrimRep t_s1ro :: (# (), () #) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/ghci/ByteCodeGen.hs:1582:5 in ghc:ByteCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Replacing `(MkUTD t)` with just `t` obtains a different error, with a nicer message: {{{#!hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Error: bytecode compiler can't handle unboxed tuples and sums. Possibly due to foreign import/export decls in source. Workaround: use -fobject-code, or compile this module to .o separately. }}} True to its word, GHCi accepts it with `-fobject-code`, but it also accepts the unwrapping one, with the worse error message, with `-fobject- code`. It only happens with unboxed tuples in GHCi: if you replace the unboxed tuple with an unboxed int, GHCi will happily accept it. GHC cheerfully compiles everything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10731: System.IO.openTempFile is not thread safe on Windows
by GHC 05 Jan '18

05 Jan '18

#10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the test program: {{{#!hs import Control.Concurrent import System.IO import Control.Monad import System.Directory main = do putStrLn "Starting" var <- newEmptyMVar tdir <- getTemporaryDirectory xs <- replicateM 10 $ do var <- newEmptyMVar flip forkFinally (\s -> do print s; putMVar var ()) $ do replicateM_ 100000 $ do (file, h) <- openTempFile tdir "test.txt" hClose h removeFile file return var mapM_ takeMVar xs }}} If I compile and run that with {{{ghc --make TmpFile.hs -threaded && tmpfile +RTS -N5}}} I get: {{{ Starting Left C:\Users\NDMIT_~1\AppData\Local\Temp\: openTempFile: permission denied (Permission denied) Left C:\Users\NDMIT_~1\AppData\Local\Temp\: openTempFile: permission denied (Permission denied) ... }}} I've reproduced this on GHC 7.8 and 7.10.1. We hit this in production about twice a day. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14607: Core Lint error
by GHC 03 Jan '18

03 Jan '18

#14607: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: TypeInType, | Operating System: Unknown/Multiple DeferredTypeErrors | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14605 #14584 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This produces long {{{#!hs {-# Language DerivingStrategies #-} {-# Language GADTs #-} {-# Language GeneralizedNewtypeDeriving #-} {-# Language InstanceSigs #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language TypeInType #-} {-# Language TypeOperators #-} import Data.Kind data DEFUNC :: Type -> Type -> Type where (:~>) :: a -> b -> DEFUNC a b type a ~> b = DEFUNC a b -> Type data LamCons a :: Type ~> Type where LamCons :: a -> LamCons a ([a] :~> [a]) class Mk (app :: Type ~> Type) where type Arg app :: Type mk :: Arg app -> app (a :~> b) instance Mk (LamCons a :: Type ~> Type) where type Arg (LamCons a) = a mk :: a -> LamCons (a :~> b) mk = LamCons }}} erros with `ghci -ignore-dot-ghci -fdefer-type-errors -dcore-lint bug.hs` on GHC 8.2.1 and 8.3.20171208. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5