July 2018 - ghc-tickets

[GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints
by GHC 02 Aug '18

02 Aug '18

#15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #12957 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE GADTs #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where f :: (Int ~ Bool) => Bool -> a f x = case x of {} g :: (Int ~ Bool) => Bool -> a g x = case x of True -> undefined }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:10:7: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: False | 10 | g x = case x of True -> undefined | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Observe that we get a non-exhaustivity warning for the `case` expression in `g` (thanks to commit adb565aa74582969bbcc3b411d6d518b1c76c3cf), but not for the one in `f`. The difference is that `f` uses `EmptyCase`, whereas `g` does not, and the codepath for `EmptyCase` is unfortunately incongruous with the codepath for other coverage checking. I know how to fix this. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15415: GHCi's :kind doesn't work with wildcards
by GHC 02 Aug '18

02 Aug '18

#15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Witness this GHCi session: {{{ rae:20:35:37 ~/ghc/ghc-head/ghc> ~/ghc/ghc-head/inplace/bin/ghc-stage2 --interactive GHCi, version 8.7.20180716: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rae/.ghc/ghci.conf Prelude> :set -XPartialTypeSignatures Prelude> import Data.Proxy Prelude Data.Proxy> :k Proxy _ Proxy _ :: * Prelude Data.Proxy> :k Proxy (Maybe :: _) <interactive>:1:8: error: • Expecting one more argument to ‘Maybe’ Expected kind ‘_’, but ‘Maybe’ has kind ‘* -> *’ • In the first argument of ‘Proxy’, namely ‘(Maybe :: _)’ In the type ‘Proxy (Maybe :: _)’ }}} It seems we're not doing the correct wildcard thing here: GHCi should report that `_` should be `Type -> Type`. I believe that this is because `TcHsType.tcWildCardBinders` uses `newSkolemTyVar` internally; `tcWildCardBinders` is called from `TcRnDriver.tcRnType`, which is the implementation of GHCi's `:kind`. This is GHC's only call of `tcWildCardBinders`. All other places use `tcWildCardBindersX newWildTyVar`, which makes vastly more sense. I would just fix this myself, but it smells intentional. Does anyone know why we have all this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15348: Enable two-step allocator on FreeBSD
by GHC 02 Aug '18

02 Aug '18

#15348: Enable two-step allocator on FreeBSD ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Currently the two-step allocator is disabled on FreeBSD as the `MEM_NORESERVE` macro is undefined. It seems that FreeBSD provided this macro until 2014, when it was [[https://reviews.freebsd.org/D848|removed]] as it wasn't implemented in the kernel. Regardless, Viktor Dukhovni reports empirical evidence on `ghc-devs` that just plain `mmap` does what we want. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #15358: no way to talk about unpacking sum types / unpacking tuples
by GHC 01 Aug '18

01 Aug '18

#15358: no way to talk about unpacking sum types / unpacking tuples -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: unboxedsums, | Operating System: Unknown/Multiple unboxedtuples | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose I have the following Haskell module: {{{#!hs {-# LANGUAGE BangPatterns #-} -- strict 'Maybe' data StrictMaybe a = SNothing | SJust !a -- lazy 'Maybe' data Maybe a = Nothing | Just a data BoxedInner = BoxedInner !Int !(Maybe Int) data StillBoxedInner = StillBoxedInner !Int !(StrictMaybe Int) mBoxed :: BoxedInner mBoxed = BoxedInner 0 (Just 0) mWantThisToUnbox :: StillBoxedInner mWantThisToUnbox = StillBoxedInner 1 (Just 1) }}} the 'StrictMaybe' can unbox the first 'Int' into 1#, but the 1 inside of the just cannot unbox. When compiled to core with -O2 what I'd want to see is something like: {{{#!hs mWantThisToUnbox = StillBoxedInner 0# (# | 1# #) }}} (where (# (# #) | a #) is an unboxed sum type with two constructors, one nullary and one unary) but instead the Int inside 'SJust' remains boxed. Even with something like the following: {{{#!hs {-# LANGUAGE UnboxedSums #-} data UMaybe a = (# (# #) | a #) }}} something like 'UMaybe Int' would still result in 'Int' being boxed. This same thing occurs with unpacked tuples, consider something like: {{{#!hs data StrictTuple = StrictTuple !Int !(Int, Int) }}} Anything inside the (Int, Int) tuple will not unbox, despite having a bang pattern there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15358> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15148: Allow setting of custom alignments
by GHC 01 Aug '18

01 Aug '18

#15148: Allow setting of custom alignments -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (NCG) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15124 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Alignment can introduce a bias to benchmarking results which isn't obvious. To help deal with that I want to add some options adjusting alignment for generated code. To give one example I came across while looking into #15124: Padding a function that **is not even called** in nofib/real/eff/FS by multiples of 8 bytes gave runtimes of ~240ms, ~220ms and ~210ms depending on the padding. At 64 byte it seems to loop around (size of a cache line). At a minimum it should be possible to specify alignment of functions. Potentially we could also consider: * Padding for sections. * Padding for functions * Alignment for info tables. * Padding for info tables. * Alignment for Data The cases where this could have benefits: ---- Problem: We optimize one subroutine changing it's size. This leads to alignment changes for the following functions making overall performance potentially worse. Here aligning functions along cache lines would make benchmarks more resilient against accidental alignment changes. ---- Problem: We might try to optimize code based on a specific benchmark. Going purely by performance of this benchmark we might end up optimizing our code for this specific benchmark instead of the general case. Varying the alignment would to check if our code simply found a optimum for the alignment caused by this benchmark or if it is generally better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression
by GHC 01 Aug '18

01 Aug '18

#15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType | 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 program typechecks on GHC 8.6.1-alpha1: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module SGenerics where import Data.Kind import Data.Type.Equality import Data.Void ----- -- singletons machinery ----- data family Sing :: forall k. k -> Type data instance Sing :: () -> Type where STuple0 :: Sing '() type Refuted a = a -> Void data Decision a = Proved a | Disproved (Refuted a) ----- -- A stripped down version of GHC.Generics ----- data U1 = MkU1 data instance Sing (z :: U1) where SMkU1 :: Sing MkU1 ----- class Generic (a :: Type) where type Rep a :: Type from :: a -> Rep a to :: Rep a -> a class PGeneric (a :: Type) where type PFrom (x :: a) :: Rep a type PTo (x :: Rep a) :: a class SGeneric k where sFrom :: forall (a :: k). Sing a -> Sing (PFrom a) sTo :: forall (a :: Rep k). Sing a -> Sing (PTo a :: k) sTof :: forall (a :: k). Sing a -> PTo (PFrom a) :~: a sFot :: forall (a :: Rep k). Sing a -> PFrom (PTo a :: k) :~: a ----- instance Generic () where type Rep () = U1 from () = MkU1 to MkU1 = () instance PGeneric () where type PFrom '() = MkU1 type PTo 'MkU1 = '() instance SGeneric () where sFrom STuple0 = SMkU1 sTo SMkU1 = STuple0 sTof STuple0 = Refl sFot SMkU1 = Refl ----- class SDecide k where -- | Compute a proof or disproof of equality, given two singletons. (%~) :: forall (a :: k) (b :: k). Sing a -> Sing b -> Decision (a :~: b) default (%~) :: forall (a :: k) (b :: k). (SGeneric k, SDecide (Rep k)) => Sing a -> Sing b -> Decision (a :~: b) s1 %~ s2 = case sFrom s1 %~ sFrom s2 of Proved (Refl :: PFrom a :~: PFrom b) -> let r :: PTo (PFrom a) :~: PTo (PFrom b) r = Refl sTof1 :: PTo (PFrom a) :~: a sTof1 = sTof s1 sTof2 :: PTo (PFrom b) :~: b sTof2 = sTof s2 in Proved (sym sTof1 `trans` r `trans` sTof2) Disproved contra -> Disproved (\Refl -> contra Refl) instance SDecide U1 where SMkU1 %~ SMkU1 = Proved Refl instance SDecide () }}} However, it throws a Core Lint error with `-dcore-lint`. The full error is absolutely massive, so I'll attach it separately. Here is the top-level bit: {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: warning: In the expression: <elided> From-type of Cast differs from type of enclosed expression From-type: U1 Type of enclosed expr: Rep () Actual enclosed expr: PFrom a_a1Fm Coercion used in cast: Sym (D:R:Rep()[0]) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #15462: fixST for lazy ST is a bit wrong
by GHC 31 Jul '18

31 Jul '18

#15462: fixST for lazy ST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #15349 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #15349 exposed a problem with repeated computations in invocations of `fixST` that should fail but can instead produce answers or even subvert safe Haskell. That has been fixed for strict `ST`, but not yet for lazy `ST`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15462> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15353: Another Cabal submodule bump
by GHC 31 Jul '18

31 Jul '18

#15353: Another Cabal submodule bump -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | 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: -------------------------------------+------------------------------------- https://github.com/snowleopard/hadrian/issues/634 uncovered a bug in Cabal that bit Hadrian quite severely. The Hadrian people are working around it, but it'd be nice if they could rip out the hacks in CI and stop having to remember to point the Cabal submodule to a fixed commit. The bug has been fixed in Cabal HEAD now, so the only thing needed is a submodule bump in GHC master, please. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15451: Fix Git commit ID detection in worktrees
by GHC 31 Jul '18

31 Jul '18

#15451: Fix Git commit ID detection in worktrees -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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): Phab:D5016 | Wiki Page: -------------------------------------+------------------------------------- When using a Git worktree, ".git" is a file, not a directory, hence "configure" doesn't detect it correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15431: Coercible and Existential types don't play nicely
by GHC 31 Jul '18

31 Jul '18

#15431: Coercible and Existential types don't play nicely -------------------------------------+------------------------------------- Reporter: NioBium | 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: -------------------------------------+------------------------------------- In the following example, {{{f}}} compiles but {{{g}}} doesn't. {{{ data T t where A :: Show (t a) => t a -> T t B :: Coercible Int (t a) => t a -> T t f :: T t -> String f (A t) = show t g :: T t -> Int g (B t) = coerce t • Couldn't match representation of type ‘Int’ with that of ‘t a’ Inaccessible code in a pattern with constructor: B :: forall k (t :: k -> *) (a :: k). Coercible Int (t a) => t a -> T t, in an equation for ‘g’ • In the pattern: B t In an equation for ‘g’: g (B t) = coerce t }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5