July 2018 - ghc-tickets

[GHC] #14341: Show instance for TypeReps is a bit broken
by GHC 15 Oct '18

15 Oct '18

#14341: Show instance for TypeReps is a bit broken -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.1 Libraries | Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4084 | Wiki Page: -------------------------------------+------------------------------------- There are two problems. 1. Showing typereps of tuples can produce unnecessary parentheses: {{{ Prelude K T> typeRep @(Int, Maybe Bool) (Int,(Maybe Bool)) }}} The fix is trivial. 2. Showing typereps of ticked (i.e., lifted) tuples and lists gives hard- to-read results, because it does not use the usual special syntax: {{{ Prelude K T> typeRep @'(Int, Maybe Bool) '(,) * * Int (Maybe Bool) Prelude K T> typeRep @'[1,2,3] ': Nat 1 (': Nat 2 (': Nat 3 ('[] Nat))) }}} Fixing the lifted tuple case is trivial. Fixing the lifted list case is slightly less trivial, but not hard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14341> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14088: Allow users to omit`forall`
by GHC 15 Oct '18

15 Oct '18

#14088: Allow users to omit`forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- Just an idea I wanted to get out there, I don't think it causes parsing ambiguity {{{#!hs -- id :: forall a. a -> a id :: a. a -> a -- everywhere :: (forall b. Term b => b -> b) -> (forall a. Term a => a -> a) everywhere :: (b. Term b => b -> b) -> (a. Term a => a -> a) }}} I think it looks beautiful but clearly more difficult to Google or grep for. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12005: Constraint instances not shown in `:info`
by GHC 13 Oct '18

13 Oct '18

#12005: Constraint instances not shown in `:info` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci -XKindSignatures -XRank2Types -XConstraintKinds -XAllowAmbiguousTypes -XInstanceSigs GHCi, version 8.1.20160428: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Kind Prelude Data.Kind> class Defer (p :: Constraint) where defer :: (p => r) -> r Prelude Data.Kind> instance Defer () where defer :: r -> r; defer = id Prelude Data.Kind> :i Defer class Defer (p :: Constraint) where defer :: (p => r) -> r {-# MINIMAL defer #-} -- Defined at <interactive>:2:1 }}} Same happens with the [https://github.com/ekmett/constraints/blob/master/src/Data/Constraint/Defer… Data.Constraint.Deferrable] which defines: {{{#!hs instance (Typeable a, Typeable b) => Deferrable (a ~ b) instance (Deferrable a, Deferrable b) => Deferrable (a, b) instance (Deferrable a, Deferrable b, Deferrable c) => Deferrable (a, b, c) }}} but no instances are shown: {{{ ghci> import Data.Constraint.Deferrable ghci> :i Deferrable class Deferrable (p :: Constraint) where deferEither :: proxy p -> (p => r) -> Either String r {-# MINIMAL deferEither #-} -- Defined in ‘Data.Constraint.Deferrable’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15053: Compiler panic on invalid syntax (unterminated pragma)
by GHC 13 Oct '18

13 Oct '18

#15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | 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: -------------------------------------+------------------------------------- The following minimal example causes a compiler panic. {{{ {-# OPTIONS_GHC -O1 } " #-} }}} {{{ ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.5.20180413 for x86_64-unknown-mingw32): getOptions'.parseToks: Couldn't read "\r\n\"\r\n " as String Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Happens in HEAD and 8.2.2 at least. Double quotes seem to confuse the parser. Also panics if there are two doublequotes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14907: Error message: (%, %) shows up when with accidental paren
by GHC 13 Oct '18

13 Oct '18

#14907: Error message: (%,%) shows up when with accidental paren -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- I accidentally wrote an extra closing parens in instance declaration {{{#!hs $ ghci -ignore-dot-ghci -XRankNTypes GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> class (Category (Src f), forall xx. xx => Eq xx)) => Functor f <interactive>:1:8: error: Unexpected type ‘Category (Src f)’ In the class declaration for ‘GHC.Classes.(%,%)’ A class declaration should have form class GHC.Classes.(%,%) a b where ... Prelude> }}} `(%,%)` shouldn't show up here, same happens on 8.5.20180105 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by GHC 13 Oct '18

13 Oct '18

#8763: forM_ [1..N] does not get fused (10 times slower than go function) ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{ -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86

[GHC] #15196: Invert floating point comparisons such that no extra parity check is required.
by GHC 13 Oct '18

13 Oct '18

#15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (NCG) | Keywords: CodeGen | 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 comment pretty much explains it already: {{{ -- We have to worry about unordered operands (eg. comparisons -- against NaN). If the operands are unordered, the comparison -- sets the parity flag, carry flag and zero flag. -- All comparisons are supposed to return false for unordered -- operands except for !=, which returns true. -- -- Optimisation: we don't have to test the parity flag if we -- know the test has already excluded the unordered case: eg > -- and >= test for a zero carry flag, which can only occur for -- ordered operands. -- -- ToDo: by reversing comparisons we could avoid testing the -- parity flag in more cases. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin
by GHC 12 Oct '18

12 Oct '18

#15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple typeable,knownnat | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following Haskell code which uses `ghc-typelits-knownnat-0.5` package as a plugin: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-} module Nats where import Data.Proxy (Proxy (..)) import Data.Typeable (Typeable) import GHC.TypeLits (KnownNat, type (+)) f :: forall n . (Typeable n, KnownNat n) => Proxy n -> () f _ = () f _ = f (Proxy :: Proxy (n + 1)) }}} When I try to compile this code I observe the following error message: {{{ • Could not deduce (Typeable (n + 1)) arising from a use of ‘f’ from the context: (Typeable n, KnownNat n) bound by the type signature for: f :: forall (n :: ghc-prim-0.5.2.0:GHC.Types.Nat). (Typeable n, KnownNat n) => Proxy n -> () at src/Nats.hs:13:1-57 • In the expression: f (Proxy :: Proxy (n + 1)) In an equation for ‘f’: f _ = f (Proxy :: Proxy (n + 1)) | 15 | f _ = f (Proxy :: Proxy (n + 1)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This code works for both GHC-8.2.2 and GHC-8.0.2. I found similar ticket with exactly this problem but looks like this is broken again: #10348 (bug). Originally reported at Github for `ghc-typelits-knownnat` package: * https://github.com/clash-lang/ghc-typelits-knownnat/issues/21 `ghc-typelits-knownnat` package correctly infers `KnownNat (n + 1)` constraint so GHC should be able to infer `Typeable (n + 1)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff.
by GHC 12 Oct '18

12 Oct '18

#13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. --------------------------------------+--------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Currently GHC HEAD segfaults on Windows 64-bit when compiling `language-c-quote-0.11.7.1` package. It spits something like `Access violation in generated code when executing data at 0000000102fbcf40` (I'm using my #13108 patch here). After repeated run, when GHC hasn't recompile all files, but only part of them, it succeeds. If I delete intermediate files and repeat clean compilation, it segfaults again. Haddock always segfaults (since it always recompile all files), more details here: https://github.com/haskell/haddock/pull/568. Since these access violations consistently happen on executable data at virtual addresses above 4GB mark, this very much smells as a GHC bytecode generator/linker issue. I believe, GHC and Haddock succeed exactly when all executable addresses stay below 4GB mark. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump-simpl
by GHC 11 Oct '18

11 Oct '18

#13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump- simpl -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- When reading core output, it is very distracting to always have to wade through a large number of bindings generated by `Typeable`. In most cases I don't care about any of these so it would be easier if there was some way to stop them being printed or being generated in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2