May 2018 - ghc-tickets

[GHC] #11766: Lazy application gives "No instance" error while strict application works
by GHC 26 May '18

26 May '18

#11766: Lazy application gives "No instance" error while strict application works -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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 might make sense if there were any IO. Here's the code: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE UndecidableInstances #-} import Data.Maybe (isJust) data Wrapper a = Wrapper a deriving (Show) class Resolution a instance Resolution (Wrapper a) class (Resolution b, Resolution d) => C a b c d | a -> b, c -> d, a d -> c, b c -> a where cfun :: (b -> d) -> a -> c instance (Resolution b, Resolution d, a ~ b, c ~ d) => C a b c d where cfun = ($) instance (Eq a, C b c d e) => C (Maybe a -> b) c (Maybe a -> d) e where cfun f b = \x -> cfun f (b x) foo :: Maybe a -> Wrapper Bool foo = Wrapper . isJust }}} Applying `Nothing` strictly or in a `let` clause gives the expected answer (I expect that `cfun id foo` would be equivalent to `foo`): {{{#!hs *Main> cfun id foo $! Nothing Wrapper False *Main> let f = cfun id foo in f Nothing Wrapper False }}} But regular application (or just `(cfun id foo) Nothing`) returns the following error: {{{#!hs *Main> cfun id foo $ Nothing <interactive>:6:1: No instance for (Resolution (Maybe a0 -> Wrapper Bool)) (maybe you haven't applied enough arguments to a function?) arising from a use of ‘cfun’ In the expression: cfun id foo In the expression: cfun id foo $ Nothing In an equation for ‘it’: it = cfun id foo $ Nothing }}} In case it helps, the purpose of this code is for `cfun` to have the effective type of {{{#!hs cfun :: (Eq a0, Eq a1, .., Eq an) => (Wrapped b -> Wrapped c) -> (Maybe a0 -> Maybe a1 -> .. -> Maybe an -> Wrapped b) -> (Maybe a0 -> Maybe a1 -> .. -> Maybe an -> Wrapped c) }}} i.e. apply a function to the "wrapped" return value of another function of the above form. Tested on GHC 8.0.1-rc2 (most recent OSX binary as of now) and 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12514: Can't write unboxed sum type constructors in prefix form
by GHC 26 May '18

26 May '18

#12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | 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: -------------------------------------+------------------------------------- You can write `(# Int | Char #)`, but not `(# | #) Int Char`. This is annoying since it prevents you from partially applying unboxed sum type constructors, and it also precludes you from doing cool things like `reify ''(#||#)` (as I woefully noted [https://phabricator.haskell.org/D2448 here]). Luckily, I don't think fixing this would be too hard. The special case of parsing unboxed tuple type constructors as prefix is handled [http://git.haskell.org/ghc.git/blob/0d3bf62092de83375025edca6f7242812338542… here], so I //think// we'd just need to add a similar case for unboxed sums. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found
by GHC 26 May '18

26 May '18

#12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TemplateHaskell, Typeable | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code produces an ghc panic error: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ScopedTypeVariables #-} module TH where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Data.Typeable usingType :: forall a. Typeable a => a -> Q [Dec] usingType _ = do -- Try to get anything using typeRep. let name = (tyConName $ typeRepTyCon $ typeRep (Proxy :: Proxy a)) `seq` "The name!" -- theF = "The name!" return [FunD (mkName "theF") [Clause [] (NormalB $ LitE $ StringL name ) []]] }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import TH data A = A Int -- Changing the argument to (A 3) does not help. $(usingType (undefined :: A)) main = putStrLn $ theF }}} The error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: $tcA [r5m0 :-> Type constructor ‘A’, r5m3 :-> Data constructor ‘A’, r5m9 :-> Identifier ‘A’] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12452: TemplateHaskell - variables in top level splices and loading modules.
by GHC 26 May '18

26 May '18

#12452: TemplateHaskell - variables in top level splices and loading modules. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux TemplateHaskell | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails when loading Main module: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ScopedTypeVariables #-} module TH where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Data.Typeable usingType :: a -> Q [Dec] usingType _ = do let name = "The name!" -- theF = "The name!" return [FunD (mkName "theF") [Clause [] (NormalB $ LitE $ StringL name ) []]] }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import TH data A = A Int -- Runs with `usingType (undefined :: A)` instead $(usingType (A 3) ) main = putStrLn $ theF }}} The error: {{{ $ ghc --make Main.hs [1 of 2] Compiling TH ( TH.hs, TH.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) attempting to use module ‘Main’ (Main.hs) which is not loaded }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13853: TypeApplications and record syntax don't mix
by GHC 26 May '18

26 May '18

#13853: TypeApplications and record syntax don't mix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Let's fire up GHCi: {{{ $ ~/Software/ghc-8.2.0.20170507/bin/ghci GHCi, version 8.2.0.20170507: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rscott/.ghci λ> :set -XTypeApplications -fprint-explicit-foralls λ> import Data.Functor.Identity }}} I can use `TypeApplications` on `Identity` like so: {{{ λ> Identity @Int 42 Identity 42 }}} But not if I try to use record syntax: {{{ λ> Identity @Int { runIdentity = 42 } <interactive>:4:15: error: parse error on input ‘{’ λ> (Identity @Int) { runIdentity = 42 } <interactive>:7:1: error: • Couldn't match expected type ‘Identity a0’ with actual type ‘Int -> Identity Int’ • In the expression: (Identity @Int) {runIdentity = 42} In an equation for ‘it’: it = (Identity @Int) {runIdentity = 42} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12093: Wrong argument count in error message with TypeApplications
by GHC 26 May '18

26 May '18

#12093: Wrong argument count in error message with TypeApplications -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I write: {{{#!hs {-# language TypeApplications #-} module Bug where wrong = id @Bool True False }}} I get the error: {{{ • Couldn't match expected type ‘Bool -> t’ with actual type ‘Bool’ • The function ‘id’ is applied to three arguments, but its type ‘Bool -> Bool’ has only one In the expression: id @Bool True False In an equation for ‘bad’: bad = id @Bool True False • Relevant bindings include bad :: t (bound at Bug.hs:8:1) }}} This seems to tell me that I ought to get rid of //two// of the arguments given to `id`, when in fact I only ought to remove //one//. In particular, the issue seems to be that GHC includes visibly applied type parameters in the count of "how many arguments is it applied to?" but does not include them in the count of "how many arguments does it have?" Suggested fix: in cases of this error with visible type application, report something akin to, "The function ‘id’ is applied to two type arguments and two value arguments, but its type has only one value argument." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12093> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7543: Constraint synonym instances
by GHC 26 May '18

26 May '18

#7543: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13267 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13267 Comment: In #13267, we decided to simply disallow instances for constraint synonyms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7543#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15038: Memory Corruption (strange closure type)
by GHC 26 May '18

26 May '18

#15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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've been encountering corruption of memory in a library of mine that uses some of GHC's more recent features (levity polymorphism and unboxed sums). The library is `packed`, and it's source code can be found on my github. But, more relevant to this issue is the minimal reproducible example I've put together here: https://github.com/andrewthad/corrupted-memory-example It's still a bit larger than I'd like it to be, and if no one has any insights into this, I can keep whittling it down to make it more minimal. Here's how to run it: {{{ git clone https://github.com/andrewthad/corrupted-memory-example cd corrupted-memory-example cabal new-build --enable-tests test ./dist-newstyle/build/corrupted-memory-example-0.1/build/test/test }}} This consistently crashes with: {{{ test: internal error: evacuate(static): strange closure type 16648 (GHC version 8.4.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Additional information: This issue can be reproduced using GHC 8.2.2, GHC 8.4.1, and GHC HEAD. This project cannot be built with GHC 8.0.2 and earlier since it uses unboxed sums. Building this project with either `stack` or `cabal new-build` and then running the test causes the same crash. However, building it with plain old GHC and then running it does not. This is really weird, since there aren't any GHC options in the cabal file that should affect this. In the original library, I have a bunch of tests that use the parsers `byte` and `any` in a variety of situations, and none of them every trigger this crash except for the ones where I stick a `Parser` inside of a `Trie`. This project does a lot of manual passing of state tokens, but I believe all of these uses to be correct (mostly because of the extensive tests in the original repo, but I've also spent a lot of time just looking at the code to figure out if this was something on my end). Let me know if the example is too big. I can spend some more time shrinking it further, but I wanted to go ahead and get it up here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #15182: Lazier Semigroup instance for Maybe
by GHC 26 May '18

26 May '18

#15182: Lazier Semigroup instance for Maybe -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Mailing list discussion here: https://mail.haskell.org/pipermail/libraries/2018-May/028818.html The existing `Semigroup` instance for `Maybe` is: {{{ instance Semigroup a => Semigroup (Maybe a) where Nothing <> b = b a <> Nothing = a Just a <> Just b = Just (a <> b) }}} It has been proposed that it be replaced by: {{{ instance Semigroup a => Semigroup (Maybe a) where Nothing <> b = b Just a <> b = Just (maybe a (a<>) b) }}} This is lazier in the second argument, making it more consistent with the strictness of the `Semigroup` instances for `And`,`Or`,`Ord`,`Either`,`Proxy` and `()`. Equivalently, we could write: {{{ instance Semigroup a => Semigroup (Maybe a) where Nothing <> b = b Just a <> Nothing = Just a Just a <> Just b = Just (a <> b) }}} This makes it a little more clear that we aren't building a closure for partial function application, but it should have the same behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15183: Expose the SNat type and the natSing method
by GHC 25 May '18

25 May '18

#15183: Expose the SNat type and the natSing method -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | 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: -------------------------------------+------------------------------------- Currently, neither the `SNat` type nor the `natSing` method of `KnownNat` are exported from `GHC.TypeLits`. This is weird and awkward. There's no apparent reason not to expose the `SNat` ''type'', although it may make sense not to expose its definition. It also could possibly make sense not to expose the fact that `natSing` is a ''method'' of `KnownNat`, but there's no apparent reason not to export a function with its type. Can we just do those? 1. Export the `SNat` type. 2. Export a function with the type of `natSing`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5