- ghc-tickets - Haskell.org

[GHC] #10037: Several profiling tests give different results optimised vs. unoptimised
by GHC 19 Apr '18

19 Apr '18

#10037: Several profiling tests give different results optimised vs. unoptimised -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Profiling | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Most of the differences are relatively harmless (mostly CAF attribution), but it would be nice to get this right. In the meantime I'll mark them expect_broken and point to this ticket. The following tests in `tests/profiling/should_run` are affected: {{{ scc001 T2552 ioprof callstack001 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14944: Compile speed regression
by GHC 19 Apr '18

19 Apr '18

#14944: Compile speed regression -------------------------------------+------------------------------------- Reporter: br1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compile time went from 5 seconds in 7.6.1 to 12 seconds in 8.2.2 and then down to 10 seconds in 8.4.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #15042: Bump unix's version number to 2.8.0.0 in HEAD
by GHC 19 Apr '18

19 Apr '18

#15042: Bump unix's version number to 2.8.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15018 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In order to perform a `unix` submodule bump (as requested in #15018), we'll need to deal with the fact that its major version number was bumped upstream to 2.8.0.0. As a result, the following boot libraries will need to be adjusted: * `Cabal` and `cabal-install` * `directory` * `haskeline` * `iserv-bin` (ready, in-place) * `process` Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds
by GHC 19 Apr '18

19 Apr '18

#14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 (Type checker) | Keywords: PolyKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Data.Coerce import Data.Proxy class C a b where c :: Proxy (x :: a) -> b newtype I a = MkI a instance C x a => C x (Bug.I a) where c = coerce @(forall (z :: x). Proxy z -> a) @(forall (z :: x). Proxy z -> I a) c }}} is rightfully rejected by GHC 8.2.2: {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:20:16: error: Unexpected kind variables Perhaps you intended to use PolyKinds In a type argument | 20 | c = coerce @(forall (z :: x). Proxy z -> a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:21:16: error: Unexpected kind variables Perhaps you intended to use PolyKinds In a type argument | 21 | @(forall (z :: x). Proxy z -> I a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But GHC 8.4.1-alpha2 actually //accepts// this program! {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180118: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. }}} This is almost certainly bogus. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14689: Load order of .ghci config files is counterintuitive
by GHC 19 Apr '18

19 Apr '18

#14689: Load order of .ghci config files is counterintuitive -------------------------------------+------------------------------------- Reporter: hal9zillion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14250, #6017 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Basically ghci seems to give precedence to global .ghci conguration settings by applying them after any local/project specific .ghci files: https://github.com/ghc/ghc/blob/314bc31489f1f4cd69e913c3b1e33236b2bdf553/gh… OTOH there are a couple of open issues where people dont like the idea of local ghci evaluation for security reasons: #6017 #14250 I suggest the following resolution: - Change the order or evaluation from global first to local - include a new ghci setting that prevents/enables the evaluation of local/project specific .ghci files for people who wish to avoid the security concerns some people have - This flag can then be set in the global .ghci file I believe this would both address the counterintuitive loading strategy implied currently (i was convinced local .ghci files didnt work because when i changed the prompt it was always overwritten by my global config) and the security question. The only question then would be if evaluation of project/local .ghci files would be on or off by default. I would favour the former but that is just personal preference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15020: PatternSynonyms: Problems with quantified constraints / foralls
by GHC 18 Apr '18

18 Apr '18

#15020: PatternSynonyms: Problems with quantified constraints / foralls -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- I couldn't find a way to implement `PLam2` as a simply bidirectional pattern synonym, I expected it to work but I recall a similar ticket. I couldn't find it though. {{{#!hs {-# Language RankNTypes, PatternSynonyms, ViewPatterns #-} newtype Lam1 = Lam1 (forall xx mm. Monad mm => mm xx) pattern PLam1 :: (forall xx mm. Monad mm => mm xx) -> Lam1 pattern PLam1 a = Lam1 a -- newtype Lam2 a = Lam2 (forall mm. Monad mm => mm a) newtype Forall f = Forall (forall xx. f xx) -- · FAILS · -- pattern PLam2 :: (forall xx mm. Monad mm => mm xx) -> Forall Lam2 -- pattern PLam2 lam = Forall (Lam2 lam) -- get :: Forall Lam2 -> forall xx mm. Monad mm => mm xx get (Forall (Lam2 lam)) = lam pattern PLam3 :: (forall xx mm. Monad mm => mm xx) -> Forall Lam2 pattern PLam3 lam <- (get -> lam) where PLam3 lam = Forall (Lam2 lam) }}} The complaint is and I wonder if this is a limitation of PatternSynonyms {{{ • Couldn't match type ‘xx0’ with ‘xx’ because type variable ‘xx’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall xx (mm :: * -> *). Monad mm => mm xx at Test.hs:16:34-36 Expected type: mm xx Actual type: mm xx0 • In the declaration for pattern synonym ‘PLam2’ • Relevant bindings include lam :: forall (mm :: * -> *). Monad mm => mm xx0 (bound at Test.hs:16:34) | 16 | pattern PLam2 lam = Forall (Lam2 lam) | ^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15052: DeriveAnyClass instances may skip TypeError constraints
by GHC 18 Apr '18

18 Apr '18

#15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- In the presence of `TypeError`, one can derive instances with `DeriveAnyClass` that would be rejected otherwise. A simplistic example would be: {{{#!haskell {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} module T where import GHC.TypeLits(TypeError, ErrorMessage(..)) class TypeError ('Text "BOOM") => C a where f :: a -> () f _ = () data T = T deriving(C) }}} Of course, any attempt to use the instance leads to a type-error. However, the instance is rejected right away using a normal instance declaration or StandaloneDeriving. While this is a toy example, it can actually happen when using `Generics` and default-signatures, where one would puts a `TypeError` in an instance head for one of the `Generics` constructors to give a better error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #5142: stub header files don't work with the MS C compiler
by GHC 18 Apr '18

18 Apr '18

#5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Azel): I'd like to have a go at this issue, is anyone working on it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5142#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop
by GHC 17 Apr '18

17 Apr '18

#12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where class C a b | a -> b where c :: a -> Int newtype Foo a = Foo a deriving (C b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #15034: Desugaring `mdo` moves a `let` where it shouldn't be
by GHC 17 Apr '18

17 Apr '18

#15034: Desugaring `mdo` moves a `let` where it shouldn't be -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE RecursiveDo #-} module Main where a :: String a = "hello" test :: IO () test = mdo putStrLn a let a = 3 :: Int print a }}} With both GHC 8.2.2 and GHC 8.4.1, it fails with the following error: {{{#!hs /home/matt/Projects/ghc-repro/src/Main.hs:10:5: error: • Couldn't match type ‘Int’ with ‘[Char]’ Expected type: String Actual type: Int • In a stmt of an 'mdo' block: rec putStrLn a let a = (3 :: Int) In the expression: mdo rec putStrLn a let a = ... print a In an equation for ‘test’: test = mdo rec putStrLn a let ... print a | 10 | putStrLn a | ^^^^^^^^^^ }}} I would expect it to succeed, with `a` shadowing the top-level definition. The desugared output in the error message tells us what is wrong: it is grouping `putStrLn a; let a = ...` together! If I alter the program to be: {{{#!hs a :: String a = "hello" test :: IO () test = do rec putStrLn a let a = 3 :: Int print a }}} Then it does the Right Thing. Looking at the [https://prime.haskell.org/wiki/RecursiveDo Haskell Prime wiki entry for Recursive Do], this seems to be the relevant bit: > That is, a variable used before it is bound is treated as recursively defined, while in a Haskell 98 do-statement it would be treated as shadowed. I have a more complicated reproduction involving `ST` types and complaints of skolem type variables escaping scope: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE RecursiveDo #-} module Main where import Control.Monad.ST theThing :: ST s () theThing = pure () weirdlyLocal :: ST s () weirdlyLocal = theThing runSTIO :: (forall s. ST s a) -> IO a runSTIO x = pure (runST x) thisWorks :: IO () thisWorks = mdo let weirdlyLocal = theThing runSTIO weirdlyLocal runSTIO weirdlyLocal thisBreaks :: IO () thisBreaks = mdo runSTIO weirdlyLocal let weirdlyLocal = theThing runSTIO weirdlyLocal thisIsFine :: IO () thisIsFine = mdo runSTIO weirdlyLocal let asdf = theThing runSTIO asdf }}} This demonstrates an even more bizarre behavior! If I move the `let` up to the top, then it no longer gets included in a `rec`, and it compiles fine. If I move it under the first statement, then I get this error: {{{#!hs /home/matt/Projects/ghc-repro/src/Main.hs:25:13: error: • Couldn't match type ‘s0’ with ‘s’ because type variable ‘s’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall s. ST s () at src/Main.hs:25:5-24 Expected type: ST s () Actual type: ST s0 () • In the first argument of ‘runSTIO’, namely ‘weirdlyLocal’ In a stmt of an 'mdo' block: runSTIO weirdlyLocal In a stmt of an 'mdo' block: rec runSTIO weirdlyLocal let weirdlyLocal = theThing • Relevant bindings include weirdlyLocal :: ST s0 () (bound at src/Main.hs:26:9) | 25 | runSTIO weirdlyLocal | ^^^^^^^^^^^^ /home/matt/Projects/ghc-repro/src/Main.hs:27:13: error: • Couldn't match type ‘s0’ with ‘s’ because type variable ‘s’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: forall s. ST s () at src/Main.hs:27:5-24 Expected type: ST s () Actual type: ST s0 () • In the first argument of ‘runSTIO’, namely ‘weirdlyLocal’ In a stmt of an 'mdo' block: runSTIO weirdlyLocal In the expression: mdo rec runSTIO weirdlyLocal let weirdlyLocal = ... runSTIO weirdlyLocal • Relevant bindings include weirdlyLocal :: ST s0 () (bound at src/Main.hs:26:9) | 27 | runSTIO weirdlyLocal | ^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4