October 2017 - ghc-tickets

[GHC] #14321: -fsolve-constant-dicts is not very robust when dealing with GADTs
by GHC 04 Oct '17

04 Oct '17

#14321: -fsolve-constant-dicts is not very robust when dealing with GADTs -------------------------------------+------------------------------------- Reporter: mpickering | 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: #9701 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I expected `-fsolve-constant-dicts` to nail #9701, it didn't fire at all but a slightly modified version does. {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeApplications #-} module Foo where data Silly a where Silly :: Ord a => a -> Silly a isItSilly :: a -> Silly a -> Bool isItSilly a (Silly x) = a < x isItSillyIntTA :: Int -> Silly Int -> Bool isItSillyIntTA = isItSilly @Int isItSillyInt :: Int -> Silly Int -> Bool isItSillyInt a x = isItSilly a x isItSillyInt2 :: Int -> Silly Int -> Bool isItSillyInt2 a (Silly x) = a < x isItSillyInt3 :: Int -> Silly Int -> Bool isItSillyInt3 a (Silly x) = isItSilly a (Silly x) }}} Both versions 2 and 3 specialise nicely using the `Int` `Ord` dictionary. The first two versions don't. I'm unsure whether it *should* fire or not but I am making this ticket to record this fact. Clonable code and core dump - https://gist.github.com/mpickering/f84a5f842861211e8e731c63e82d5c01 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14315: GHC panic caused by destructuring with qualified name
by GHC 04 Oct '17

04 Oct '17

#14315: GHC panic caused by destructuring with qualified name ----------------------------------------+--------------------------------- Reporter: bloxx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I have a cabal project with the following files: {{{#!hs -- src/Alt.hs module Alt where data Pizza = Pizza { filling :: String } -- =========== -- src/Main.hs module Main where import qualified Alt as A data Pizza = Pizza { filling :: String } unpizza :: A.Pizza -> String -- to fix it, replace "filling" with "A.filling" unpizza A.Pizza { filling = filling } = filling main :: IO () main = putStrLn "Hello Haskell!" }}} Of course, this is not valid code. "filling" belongs to "Pizza" and "A.filling" belongs to "A.Pizza". But it causes a panic in GHC 8.2.1 instead of an error, so I suppose it is a bug. Can you reproduce this behavior? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14292: Coercing between constraints of newtypes
by GHC 04 Oct '17

04 Oct '17

#14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- This doesn't work {{{#!hs {-# Language ConstraintKinds #-} {-# Language GADTs #-} import Data.Coerce newtype USD = USD Int data Dict c where Dict :: c => Dict c num :: Dict (Num Int) -> Dict (Num USD) num = coerce }}} but this does {{{#!hs data NUM a = NUM (a -> a -> a) num' :: NUM Int -> NUM USD num' = coerce }}} is this a fundamental limitation? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics
by GHC 04 Oct '17

04 Oct '17

#11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} module Pat (Vec2(Nil,(:>)), pattern (:>)) where newtype Vec2 a = Vec2 {unvec2 :: [a]} pattern Nil :: Vec2 a pattern Nil = Vec2 [] pattern (:>) x xs <- ((\ys -> (head $ unvec2 ys,Vec2 . tail $ unvec2 ys)) -> (x,xs)) where (:>) x xs = Vec2 (x:unvec2 xs) }}} and {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Main where import Pat (Vec2(..),pattern (:>)) }}} I get: {{{ $ ghci Main.hs GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling Pat ( Pat.hs, interpreted ) Pat.hs:2:29: warning: [-Wduplicate-exports] ‘:>’ is exported by ‘(:>)’ and ‘Vec2(Nil, type (:>))’ [2 of 2] Compiling Main ( Main.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160411 for x86_64-unknown-linux): filterImports/combine (:>, :>, Nothing) (:>, Vec2{Vec2, :>, Nil}, Nothing) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Now, the warning about the duplicate export is of course correct. But the panic shouldn't happen when I try to import both the associated pattern synonym and the normal pattern synonym. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14314: Consider changing CC detection strategy
by GHC 04 Oct '17

04 Oct '17

#14314: Consider changing CC detection strategy -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- Currently we grep through the `$CC --version` output to identify the C compiler (see `FP_GCC_VERSION` in `aclocal.m4`). This is error prone (see Phab:D4069). Phyx suggests that we instead just rely on CPP macros. There is a handy list of these [[https://sourceforge.net/p/predef/wiki/Compilers/|here]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12747: INLINE vs NOINLINE vs <nothing> give three different results; two would be better
by GHC 04 Oct '17

04 Oct '17

#12747: INLINE vs NOINLINE vs <nothing> give three different results; two would be better -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | 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: -------------------------------------+------------------------------------- INLINE vs NOINLE vs <nothing> for this function https://github.com/LambdaHack/LambdaHack/blob/master/Game/LambdaHack/Client… produces distinct figures in all three cases. See https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7 and some later comments, but I'd like to move here the discussion of the specific feature request that <nothing> should at any given point be equivalent to either INLINE or NOINLINE. Three different results are very unwieldy while optimizing code, because one cannot tweak the INLINE pragma for functions in isolation, via fixing INLINE or NOINLINE for all other functions and varying only one, because the optimal setting for some functions may be <nothing>, and it naturally varies (as it should; that is fine; but in each particular codebase/compilation flags state it should be equal to either of INLINE or NOINLINE). It seems almost as if GHC considers a function for inlining in some stages, optimizes accordingly, but changes its mind in other places, not being bound by either INLINE nor NOINLINE, and so the resulting stack of optimizations is different than in either case. IMHO that's too complex behaviour for the programmer to follow, it should irreversibly decide whether to inline at exactly the same place it first takes into account the NO/INLINE pragmas, if present. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12747> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14305: Missing COMPLETE pragmas in release notes for version 8.2.1
by GHC 03 Oct '17

03 Oct '17

#14305: Missing COMPLETE pragmas in release notes for version 8.2.1 -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Documentation | 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: -------------------------------------+------------------------------------- From comment ticket:8779#comment:57 it seems `COMPLETE` pragmas were added in 8.2.1 but I couldn't find them in its [https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/8.2.1-notes.… release notes]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13561: Remove unsafe Chan combinators
by GHC 03 Oct '17

03 Oct '17

#13561: Remove unsafe Chan combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.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: #4154 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Namely `isEmptyChan` and `unGetChan`. See #4154. Let's delete them for 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14304: Instantiated libraries (Backpack) don't get linked with enough deps
by GHC 03 Oct '17

03 Oct '17

#14304: Instantiated libraries (Backpack) don't get linked with enough deps -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 (Linking) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One downstream instance of this reported at https://github.com/haskell/cabal/issues/4755 Basically, if you instantiate a library q with library p, you need to make sure libHSp.so shows up in its linker dependencies. This is not the case right now. Patch coming (I filed this to get a bug number :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13848: Unexpected order of variable quantification with GADT constructor
by GHC 03 Oct '17

03 Oct '17

#13848: Unexpected order of variable quantification with GADT constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- Here's some code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} module Foo where data N = Z | S N data Vec (n :: N) a where VNil :: forall a. Vec Z a VCons :: forall n a. a -> Vec n a -> Vec (S n) a }}} I want to use `TypeApplications` on `VCons`. I tried doing so in GHCi: {{{ GHCi, version 8.2.0.20170523: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, modules loaded: Foo. λ> :set -XTypeApplications -XDataKinds λ> :t VCons @Z @Int 1 VNil <interactive>:1:8: error: • Expected a type, but ‘'Z’ has kind ‘N’ • In the type ‘Z’ In the expression: VCons @Z @Int 1 VNil <interactive>:1:11: error: • Expected kind ‘N’, but ‘Int’ has kind ‘*’ • In the type ‘Int’ In the expression: VCons @Z @Int 1 VNil <interactive>:1:17: error: • Couldn't match type ‘'Z’ with ‘Int’ Expected type: Vec Int 'Z Actual type: Vec 'Z 'Z • In the fourth argument of ‘VCons’, namely ‘VNil’ In the expression: VCons @Z @Int 1 VNil }}} Huh? That's strange, I would have expected the first type application to be of kind `N`, and the second to be of kind `*`. But GHC disagrees! {{{ λ> :set -fprint-explicit-foralls λ> :type +v VCons VCons :: forall a (n :: N). a -> Vec n a -> Vec ('S n) a }}} That's downright unintuitive to me, since I explicitly specified the order in which the quantified variables should appear in the type signature for `VCons`. Similarly, if you leave out the `forall`s: {{{#!hs data Vec (n :: N) a where VNil :: Vec Z a VCons :: a -> Vec n a -> Vec (S n) a }}} Then `:type +v` will also report the same quantified variable order for `VCons`. This is perhaps less surprising, since the `n` and `a` in `data Vec (n :: N) a` don't scope over the constructors, so GHC must infer the topological order in which the variables appear in each constructor. But I would certainly not expect GHC to do this if I manually specify the order with `forall`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9