October 2017 - ghc-tickets

[GHC] #14203: GHC-inferred type signature doesn't actually typecheck
by GHC 03 Nov '17

03 Nov '17

#14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 code typechecks: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data family Sing :: k -> * data Sigma (a :: *) :: (a ~> *) -> * where MkSigma :: forall (a :: *) (p :: a ~> *) (x :: a). Sing x -> Apply p x -> Sigma a p data instance Sing (z :: Sigma a p) where SMkSigma :: Sing sx -> Sing px -> Sing (MkSigma sx px) }}} I was curious to know what the full type signature of `SMkSigma` was, so I asked GHCi what the inferred type is: {{{ λ> :i SMkSigma data instance Sing z where SMkSigma :: forall a (p :: a ~> *) (x :: a) (sx :: Sing x) (px :: Apply p x). (Sing sx) -> (Sing px) -> Sing ('MkSigma sx px) }}} I attempted to incorporate this newfound knowledge into the program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data family Sing :: k -> * data Sigma (a :: *) :: (a ~> *) -> * where MkSigma :: forall (a :: *) (p :: a ~> *) (x :: a). Sing x -> Apply p x -> Sigma a p data instance Sing (z :: Sigma a p) where SMkSigma :: forall a (p :: a ~> *) (x :: a) (sx :: Sing x) (px :: Apply p x). Sing sx -> Sing px -> Sing (MkSigma sx px) }}} But to my surprise, adding this inferred type signature causes the program to no longer typecheck! {{{ GHCi, version 8.3.20170907: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:23:31: error: • Expected kind ‘Apply p0 x’, but ‘px’ has kind ‘Apply p1 x’ • In the first argument of ‘Sing’, namely ‘px’ In the type ‘Sing px’ In the definition of data constructor ‘SMkSigma’ | 23 | Sing sx -> Sing px -> Sing (MkSigma sx px) | ^^ }}} I'm showing the output of GHC HEAD here, but this bug can be reproduced all the way back to GHC 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10577: Use empty cases where appropriate when deriving instances for empty types
by GHC 02 Nov '17

02 Nov '17

#10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In some sense the correct instance for {{{ data X deriving instance Eq X }}} is not (what GHC currently produces) {{{ instance Eq X where (==) = error "Void ==" }}} but rather {{{ instance Eq X where a == b = case a of {} -- using the EmptyCase extension }}} See comments starting at ticket:7401#comment:28 for justification. The list of classes that GHC can currently derive is * Eq, Ord, Enum, Bounded, Show, Read (Haskell 2010 Report) * Functor, Foldable, Traversable, Typeable, Generic, Data, "any class" (`-XDerive*`) Deriving Enum and Bounded is not currently allowed for empty data types. The `showList` method of Show and the whole Read instance are easy and already implemented correctly. All the remaining methods of Haskell 2010 derivable type classes take at least one argument of the instance head type `a`. I propose that all these methods be defined as an empty case on the first such argument. Similarly in Functor, Foldable and Traversable, each method has a single argument of the form `t _` where `t :: * -> *` is the instance head type, and the method should be defined as an empty case on that argument. In all these cases so far, the derived methods for a non-empty type would, at the outermost level, be a (non-empty) case on that first argument, or the equivalent (series of pattern matches, one for each constructor), so the use of an empty case is justified for an empty type. Typeable does not care about the values or even the kind of the type at all, so it's not relevant here. Generic and especially Data are above my pay grade, but generally I expect that methods which are normally defined by case analysis on an argument of the instance head type should be defined by an empty case, and methods that (sometimes) produce a value of the instance head type should do whatever they normally do when unable to produce such a value (like `readsPrec` returning an empty list, or `read` calling `error` (if `read` were actually a method of `Read`)). `DeriveAnyClass` doesn't generate any new code, so like Typeable it's not relevant. None of this behavior is specified by the Haskell 2010 Report, which disallows deriving any class for a type with no constructors; but see #7401. So, we are entitled to do what we think is best here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10871: Implement "buildable" interface files which can be directly compiled without source
by GHC 02 Nov '17

02 Nov '17

#10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command-line interface is something like (subject to bikeshedding): {{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}} The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful: 1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. And maybe more we haven't thought of yet. The primary function you need to implement is a function from `ModIface`/`ModDetails` to `TcGblEnv`, which can then be fed to the desugarer. I'm looking at what things we need to add to `ModIface` to support this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le
by GHC 02 Nov '17

02 Nov '17

#12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le ---------------------------------+------------------------------------- Reporter: michelmno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+------------------------------------- as detailed in attached log below the initial failure is a reported Segmentation Fault and if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13117: Derived functor instance for void types handles errors badly
by GHC 02 Nov '17

02 Nov '17

#13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- If we have {{{#!hs data V a deriving (Functor) }}} and we evaluate {{{#!hs f <$> (error "Boo!" :: Void) }}} we should really get a "Boo" error, rather than a useless "Void fmap" one. The offending code is in `compiler/typecheck/TcGenFunctor.hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8171: Extending ExtendedDefaultRules
by GHC 02 Nov '17

02 Nov '17

#8171: Extending ExtendedDefaultRules ------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The current `ExtendedDefaultRules` is set up in a way that largely prevents it from being used for scenarios beyond what they get used for in GHCi today. It would be great if there was an extra class that could be included in the list of acceptable classes for Rule 3. {{{ class Defaulting a }}} The proposed change would be that Rule 3 under EDR can be be relaxed to: At least one of the classes Ci is numeric, or is `Show`, `Eq`, `Ord` or `Defaulting`. I went with `Defaulting` rather than `Default`, because `Default` is a common class in use across the ecosystem from the `data-default` package, and I wanted to avoid gratuitous fallout. This would permit projects like Shae Erisson's `ghclive` from last year that need to use defaulting to not have to shoe-horn unnecessary `Show` constraints onto functions. Even better would be for that class to be polykinded! That opens up possibilities for expert users to get defaulting to fire on arguments of other kinds, which is impossible under the current EDR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14347: Top-level RecordWildCards no longer working.
by GHC 02 Nov '17

02 Nov '17

#14347: Top-level RecordWildCards no longer working. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- {{{#!hs $ ghc -fforce-recomp /tmp/Damn.hs /tmp/T.hs [1 of 2] Compiling Damn ( /tmp/Damn.hs, /tmp/Damn.o ) [2 of 2] Compiling T ( /tmp/T.hs, /tmp/T.o ) /tmp/T.hs:7:5: warning: [-Wmissing-fields] • Fields of ‘D.D’ not initialised: x, y • In the expression: D.D {..} In an equation for ‘d’: d = D.D {..} | 7 | d = D.D {..} | ^^^^^^^^ $ cat /tmp/Damn.hs /tmp/T.hs module Damn (D(..)) where data D = D { x :: Int, y :: () } {-# LANGUAGE RecordWildCards #-} module T where import qualified Damn as D d :: D.D d = D.D {..} x :: Int x = 7 y :: () y = () $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 }}} Meanwhile on 8.0 {{{#!hs $ ghc -Wall -fforce-recomp /tmp/Damn.hs /tmp/T.hs [1 of 2] Compiling Damn ( /tmp/Damn.hs, /tmp/Damn.o ) [2 of 2] Compiling T ( /tmp/T.hs, /tmp/T.o ) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9249: Link to "latest" user's guide
by GHC 01 Nov '17

01 Nov '17

#9249: Link to "latest" user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I search (say, on Google) for a GHC-related bit of documentation, I variously get referred to old manuals. There doesn't seem to a good way for us, the GHC devs, to avoid this. But, perhaps we can include some information in the header of the pages to allow visitors to link to the latest manual, or perhaps to several versions. This header should also include the version number of the GHC that the page is documenting; currently, this info is only in the URL. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13772: Cannot put HasCallStack on instances
by GHC 01 Nov '17

01 Nov '17

#13772: Cannot put HasCallStack on instances -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- I'd like to get stack traces even when I'm using methods from a class, but I don't seen to be able to put HasCallStack in instance declarations. See attached code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13285: Bug in GHC.Stack.callStack when used with sections
by GHC 01 Nov '17

01 Nov '17

#13285: Bug in GHC.Stack.callStack when used with sections -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since GHC {{{8.0.1}}} call stacks are not constructed consistently anymore. Specifically, no stack frames are added for call sites that use section syntax. This used to work with GHC {{{7.10.2}}}. I haven't tried with {{{7.10.3}}}. Call stacks are used in {{{hspec}}} and {{{HUnit}}} to attach location information to failing test cases. Moreover, it is somewhat common to use section syntax with {{{hspec}}}. This is why I describe the bug in the context of {{{hspec}}}. But first, I give minimal steps on how to reproduce without the need of any additional dependencies. = TL;DR Minimal steps to reproduce {{{ #!haskell -- Main.hs import GHC.Stack main :: IO () main = do foo 23 42 (`foo` 23) 42 foo :: HasCallStack => Int -> Int -> IO () foo _ _ = print (length . getCallStack $ callStack) }}} {{{ $ runhaskell Main.hs }}} expected output: {{{ 1 1 }}} actual output: {{{ 1 0 }}} = Description of the bug from a users perspective (in the context of Hspec) This section describes the bug in the context of {{{hspec}}}. If you already understand how this bug affects users and why this is problematic you may choose to skip this section. == A working example Looking at the following example {{{ #!haskell -- Spec.hs import Test.Hspec main :: IO () main = hspec $ do it "works for my use case" $ do 23 `shouldBe` 42 }}} call stacks work as expected: {{{ $ runhaskell Spec.hs ... Failures: Spec.hs:6: 1) works for my use case expected: 42 but got: 23 ... }}} The users sees a source locations that points him to the failing test case. == A slightly modified and broken example If we rephrase the above example using section syntax we get {{{ #!haskell -- Spec.hs import Test.Hspec main :: IO () main = hspec $ do it "works for my use case" $ do (`shouldBe` 42) 23 }}} and things suddenly go bad: {{{ $ runhaskell Spec.hs ... Failures: src/Test/Hspec/Expectations.hs:91: 1) works for my use case expected: 42 but got: 23 ... }}} The user expects to see the call site of {{{shouldBe}}}, that points him to the failing test case. But instead he gets an unhelpful location that points somewhere at the implementation of {{{hspec-expectations}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5