August 2018 - ghc-tickets

[GHC] #10193: TypeRep Show instance doesn't add parens around type operators
by GHC 24 Sep '18

24 Sep '18

#10193: TypeRep Show instance doesn't add parens around type operators -------------------------------------+------------------------------------- Reporter: | Owner: pawel.nowak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc3 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Incorrect result Keywords: | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE AutoDeriveTypeable #-} {-# LANGUAGE TypeOperators #-} import Data.Typeable data a :*: b = Pair a b main = print (typeOf (Pair 'a' 'b')) }}} prints {{{#!hs :*: Char Char }}} which is not valid Haskell. I belive it should print {{{#!hs (:*:) Char Char }}} In my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation: {{{#!hs let type_str = show $ Data.Typeable.typeOf wit ... let expr_typesig = concat [parens e, " :: ", type_str] }}} What results in a parse error. I can write a patch if someone confirms that's the desired behavior and doesn't break anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15584: nonVoid is too conservative w.r.t. strict argument types
by GHC 23 Sep '18

23 Sep '18

#15584: nonVoid is too conservative w.r.t. strict argument types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #15305 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the implementation of the pattern-match coverage checker, the `nonVoid` function checks is some `Type` is inhabitable by at least one constructor. However, `nonVoid` currently does not recursively call itself on the strict argument types of each constructor that is considered. This means that certain exhaustive functions are mistakenly flagged as non- exhaustive, such as in the following example: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# OPTIONS -Wincomplete-patterns #-} module Bug where import Data.Void data V = MkV !Void data S = MkS !V f :: S -> a f x = case x of {} }}} {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.7.20180827: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:11:7: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: (MkS _) | 11 | f x = case x of {} | ^^^^^^^^^^^^ }}} The natural solution would be to call `nonVoid` recursively on strict argument types, so as to be able to tell that `S` in uninhabitable. But we can't just do this willy nilly, since we could run into infinite loops with recursive examples like this one: {{{#!hs data Abyss = MkAbyss !Abyss stareIntoTheAbyss :: Abyss -> a stareIntoTheAbyss x = case x of {} }}} Better solution: put a recursive type checker into `nonVoid`, and bail out if recursion is detected. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15325: Panic in getIdFromTrivialExpr with -fdefer-type-errors
by GHC 23 Sep '18

23 Sep '18

#15325: Panic in getIdFromTrivialExpr with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Steps to reproduce: Put this in `bug.hs`: (It's a very failed attempt to make a polymorphic list maker function.) {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} module PolyvariadicFunctions where class PolyList e a where polyList :: ([e] -> [e]) -> a -- instance PolyList e [e] where -- polyList dl = dl [] instance (e ~ e2, PolyList e a) => PolyList e (e2 -> a) where polyList dl x = polyList ((x :) . dl) plh :: [Integer] plh = polyList 1 2 3 4 5 }}} Load it in GHCi with `-fdefer-type-errors` to get the following output. Note the 'panic' in the end, and also note that the last `>` line is a no- module-loaded GHCi prompt. The question marks `?` seem to be encoding related and not relevant. This panic not seem to occur with GHC the compiler. The rest of the error messages seem otherwise identical. {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -fdefer-type-errors Prelude> :l bug.hs [1 of 1] Compiling PolyvariadicFunctions ( bug.hs, interpreted ) bug.hs:17:7: warning: [-Wdeferred-type-errors] ? No instance for (PolyList t0 [Integer]) arising from a use of ‘polyList’ ? In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^^^^^^^^^^^^^^^^^^ bug.hs:17:16: warning: [-Wdeferred-type-errors] ? No instance for (Num ([t0] -> [t0])) arising from the literal ‘1’ (maybe you haven't applied a function to enough arguments?) ? In the first argument of ‘polyList’, namely ‘1’ In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^ bug.hs:17:18: warning: [-Wdeferred-type-errors] ? Ambiguous type variable ‘t0’ arising from the literal ‘2’ prevents the constraint ‘(Num t0)’ from being solved. Probable fix: use a type annotation to specify what ‘t0’ should be. These potential instances exist: instance Num Integer -- Defined in ‘GHC.Num’ instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ ...plus two others (use -fprint-potential-instances to see them all) ? In the second argument of ‘polyList’, namely ‘2’ In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): getIdFromTrivialExpr case $dNum_a1Be of wild_00 { } Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler\\coreSyn\\CoreUtils.hs:883:18 in ghc:CoreUtils Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11155: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info"
by GHC 23 Sep '18

23 Sep '18

#11155: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 error popped up when Alan was coding the solution for #11028. The error is utterly unrelated to what Alan was working on. Here's a reproducer {{{ {-# OPTIONS_GHC -O -fno-full-laziness #-} module Main where foo :: Bool {-# NOINLINE foo #-} foo = error "rk" bar x = let t :: Char t = case foo of { True -> 'v'; False -> 'y' } in [t] main = print (bar ()) }}} Just compile that and you get {{{ Foo.o: In function `c1Sm_info': (.text+0x29a): undefined reference to `stg_ap_0_upd_info' }}} Why do we get that unresolved symbol? The STG code for `bar` looks like {{{ Main.bar :: forall t_aup. t_aup -> [GHC.Types.Char] [GblId, Arity=1, Str=DmdType <L,A>m2, Unf=OtherCon []] = \r srt:SRT:[rf :-> Main.foo] [x_s1RR] let { sat_s1RT [Occ=Once] :: GHC.Types.Char [LclId, Str=DmdType] = \u srt:SRT:[rf :-> Main.foo] [] Main.foo; } in : [sat_s1RT GHC.Types.[]]; }}} Look at that: an updatable thunk saying `sat_s1RT = Main.foo`! The error message is terrible, but the problem is a thunk whose only payload is a single variable. Why does that happen? The Core is {{{ bar = \ (@ t_aup) _ -> let t::Char = case foo of wild_00 { } in : @ Char t ([] @ Char) }}} The `case` is needed to change `foo`'s type from `Bool` to `Char`. The Core-to-STG pass drops the empty case alternatives as useless (rightly), but leaves a bare variable as the RHS, which confuses the code generator. We should clearly substitute `Main.foo` for `t`, either in Core-to-STG, or during code generation. Why hasn't this happened before now? It is quite hard to provoke, because floating the thunk for `t` to top level stops it happening. So it only happens if you switch off full laziness (as my test case here does), or if some very delicate inlining happens after the last float-out. The latter is very rare, but it's what happened to Alan. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8281: The impossible happened: primRepToFFIType
by GHC 21 Sep '18

21 Sep '18

#8281: The impossible happened: primRepToFFIType -----------------------------------+--------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I ran into this error while trying to use GHCi on the hashable package: {{{ $ cabal repl Preprocessing library hashable-1.2.0.10... GHCi, version 7.6.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. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading object (static) dist/build/cbits/fnv.o ... done Loading object (static) dist/build/cbits/getRandomBytes.o ... done final link ... done [1 of 4] Compiling Data.Hashable.RandomSource ( Data/Hashable/RandomSource.hs, interpreted ) [flags changed] [2 of 4] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, interpreted ) [flags changed] ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-apple-darwin): primRepToFFIType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #13700: GHCi command listing possible type class instances
by GHC 21 Sep '18

21 Sep '18

#13700: GHCi command listing possible type class instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- This is a reminder ticket, I want to be able to list possible instances, {{{ >>> :insts Product (Functor f, Functor g) => Functor (Product f g) (Applicative f, Applicative g) => Applicative (Product f g) ... >>> :insts Product Identity Functor g => Functor (Product Identity g) Applicative g => Applicative (Product Identity g) Monad g => Monad (Product Identity g) MonadFix g => MonadFix (Product Identity g) MonadZip g => MonadZip (Product Identity g) ... >>> :insts Product Identity Identity Functor (Product Identity Identity) Applicative (Product Identity Identity) Monad (Product Identity Identity) MonadFix (Product Identity Identity) MonadZip (Product Identity Identity) }}} Would be so useful for `GeneralizedNewtypeDeriving` {{{#!hs newtype Pair a = P (Product Identity Identity a) deriving (Functor, Applicative, Monad, MonadFix, MonadZip, ...) -- pattern (:#) :: a -> a -> Pair a -- pattern a1 :# a2 = P (Identity a1 `Pair` Identity a2) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11671: Allow labels starting with uppercase with OverloadedLabels
by GHC 21 Sep '18

21 Sep '18

#11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- The following program {{{#!hs {-# LANGUAGE OverloadedLabels, DataKinds, FlexibleInstances, MultiParamTypeClasses #-} import GHC.OverloadedLabels instance IsLabel "Three" Int where fromLabel _ = 3 test :: Int test = #Three main :: IO () main = print test }}} fails to compile in ghc 8.0 with a parse error (while it works as expected if we replace "Three" -> "three"). This may be a conscious design decision, but if not I figured I would ask if it would be possible to allow such labels starting with uppercase letters. I run into this when working on adding support for OverloadedLabels to the gobject-introspection bindings (autogenerated bindings for gtk, etc.), where it would be natural in a few places to write overloaded labels starting with a capital letter. Not hugely important, but sometimes aesthetically more pleasing (imho), and I am not aware of a good reason to forbid them. Perhaps there is one? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #13233: typePrimRep panic while compiling GHC with profiling
by GHC 20 Sep '18

20 Sep '18

#13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am seeing this panic while compiling GHC stage2, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20170124 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a :: TYPE k0) k0 Call stack: ?callStack, called at compiler/utils/Util.hs:1352:50 in ghc:Util prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <<ghc: 1038844096 bytes, 158 GCs, 21564561/73278928 avg/max bytes residency (8 samples), 148M in use, 0.000 INIT (0.000 elapsed), 1.113 MUT (1.125 elapsed), 0.935 GC (0.940 elapsed) :ghc>> compiler/ghc.mk:582: recipe for target 'compiler/stage2/build/StgCmmMonad.p_o' failed }}} This appears to be due to my enabling of profiling. `build.mk` contains, {{{ BuildFlavour=prof ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif HADDOCK_DOCS=YES compiler_HC_OPTS += -fprof-auto-exported }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 47

[GHC] #14941: Switching direct type family application to EqPred (~) prevents inlining in code using vector (10x slowdown)
by GHC 20 Sep '18

20 Sep '18

#14941: Switching direct type family application to EqPred (~) prevents inlining in code using vector (10x slowdown) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs selectVectorDestructive2 :: (PrimMonad m, VG.Vector v e, Ord e, Show e, VG.Mutable v ~ vm) => Int -> v e -> vm (PrimState m) e -> Int -> Int -> m () -- slow selectVectorDestructive2 :: (PrimMonad m, VG.Vector v e, Ord e, Show e) => Int -> v e -> VG.Mutable v (PrimState m) e -> Int -> Int -> m () -- fast }}} These two functions are identical except one has `VG.Mutable v ~ vm` as a constraint, the other one has it in the type signature right of the `=>`. The second function is 10x faster. I would expect them to be equally fast. The code of the functions is identical, I change only the type declaration. The slowness happens because with the first function, inlining of primitives like `unsafeRead` does not happen, and thus also it boxes the `Int#`s back to `Int`s when calling `unsafeRead`. In particular, in `-ddump-simpl`, the slow version has {{{#!hs $wpartitionLoop2_rgEy :: forall (m :: * -> *) (vm :: * -> * -> *) e. (PrimMonad m, MVector vm e, Ord e) => vm (PrimState m) e -> GHC.Prim.Int# -> e -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> m Int $wpartitionLoop2_rgEy = \... -> let { endIndex_a7Ay :: Int ... endIndex_a7Ay = GHC.Types.I# ww2_sfZn } in ... (VGM.basicUnsafeRead ... endIndex_a7Ay) ... }}} while the fast version has {{{#!hs $w$spartitionLoop2_rgUN :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.MutableByteArray# GHC.Prim.RealWorld -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) ... $spartitionLoop2_rgUP :: VG.Mutable VU.Vector (PrimState IO) Int -> Int -> Int -> Int -> Int -> Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) }}} So with `VG.Mutable v (PrimState m) e` in the type signature, GHC managed to inline + specialise it all the way down to concrete types (`VUM.MVector`, `IO`, and `Int` as the element type), and consequently inline `basicUnsafeRead` on unboxed `Int#`. But with `VG.Mutable v ~ vm`, ghc keeps `vm (PrimState m) e` all the way, passes around dictionaries, thus eventually cannot inline `basicUnsafeRead` and re-packs already unboxed values, like `endIndex_a7Ay = GHC.Types.I# ww2_sfZn`, before passing them into the non-inlined call of `basicUnsafeRead`, thus making a tight loop allocate that normally wouldn't allocate. Why might rewriting the type signature in such a trivial way make this happen? ---- I have tested this on GHC 8.0.2, GHC 8.2.2, and GHC 8.5 HEAD commit cc4677c36ee. Reproducer: * https://github.com/nh2/haskell-quickselect-median-of- medians/blob/0efd6293e779fda2d864ec3d75329fb16b8af6d9/Main.hs#L506 * Running instructions are [https://github.com/nh2/haskell-quickselect- median-of-medians/commit/7a49d673990dfaebdb0ba837c3fbbaae0455dba0 in this commit message]; for short: `stack exec -- ghc -O --make Main.hs -rtsopts -ddump-simpl -dsuppress-coercions -fforce-recomp -ddump-to-file -fno-full- laziness && ./Main +RTS -sstderr` * For that file, I have pregenerated `-dverbose-core2core` output here: https://github.com/nh2/haskell-quickselect-median-of- medians/tree/0efd6293e779fda2d864ec3d75329fb16b8af6d9/slowness-analysis * I originally just wanted to write a fast median-of-medians implementation on ZuriHac 2017, but got totally derailed by this performance problem. The version of it that I link here is a total mess because of me mauling it to track down this performance issue. Trying to increase `-funfolding-use-threshold` or `-funfolding-keeness- factor` did not change the situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15544: Possible segmentation fault in cryptohash-sha256 testsuite
by GHC 19 Sep '18

19 Sep '18

#15544: Possible segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ $ cabal get cryptohash-sha256-0.11.101.0 $ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer=cryptohash- sha256:base,*:stm,*:tasty,async:base test:test-sha256 -- -j 8 --quickcheck-tests 9999 }}} Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34