January 2016 - ghc-tickets

[GHC] #11099: Incorrect warning about redundant constraints
by GHC 12 May '16

12 May '16

#11099: Incorrect warning about redundant constraints -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | 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: -------------------------------------+------------------------------------- The following program results in an incorrect warning about a redundant constraint: {{{ {-# LANGUAGE TypeFamilies #-} type family SomeFun a f :: (SomeFun i ~ [a], Read a) => proxy i -> a f _ = read "HELLO" }}} This is the warning: {{{ Redundant constraint: SomeFun i ~ [a] In the type signature for: f :: (SomeFun i ~ [a], Read a) => proxy i -> a }}} I tried it on GHC version 7.11.20151029 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10181: Lint check: arity invariant
by GHC 11 May '16

11 May '16

#10181: Lint check: arity invariant -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | 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: | -------------------------------------+------------------------------------- The Arity of an ID should not exceed the arity of its type, nor the arity of its strictness signature, if it is a bottoming signatures. This should be checked by a lint check (suggested by SPJ in https://phabricator.haskell.org/D747?id=2498#inline-6058) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9478: Partial type signatures
by GHC 10 May '16

10 May '16

#9478: Partial type signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D168 -------------------------------------+------------------------------------- This ticket tracks progress on '''partial type signatures'''. * Wiki page [wiki:PartialTypeSignatures] * Phabricator link: Phab:D168 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9478> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11432: Cannot export operator newtype
by GHC 10 May '16

10 May '16

#11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 {-# LANGUAGE TypeOperators #-} module Main (main, (-.->)(..)) where main :: IO () main = return () newtype (f -.-> g) a = Fn { apFn :: f a -> g a } }}} Fails to compile with {{{ [1 of 1] Compiling Main ( fn.hs, interpreted ) fn.hs:2:20: error: Not in scope: ‘-.->’ fn.hs:2:20: error: The export item ‘(-.->)(..)’ attempts to export constructors or class methods that are not visible here }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #10775: Enable PolyKinds in GHC.Generics
by GHC 06 May '16

06 May '16

#10775: Enable PolyKinds in GHC.Generics -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As suggested in [https://mail.haskell.org/pipermail/libraries/2015-July/025981.html this] Haskell libraries mailing list thread. Among other benefits, this would allow use of generic functions with `Proxy t` when `t` is of a kind other than `*`. There seem to be more changes required than just putting `{-# LANGUAGE PolyKinds #-}` in `GHC.Generics`, however, since I tried doing that myself and found myself unable to properly derive `Generic(1)` instances in `GHC.Generics`. Here is a snippet of the resulting error message: {{{ libraries/base/GHC/Generics.hs:826:1: error: Couldn't match type ‘M1 i0 c0 (M1 i1 c1 U1) p0’ with ‘M1 D x’ Expected type: Rep (Proxy t) x Actual type: M1 i0 c0 (M1 i1 c1 U1) p0 Relevant bindings include from :: Proxy t -> Rep (Proxy t) x (bound at libraries/base/GHC/Generics.hs:826:1) In the expression: M1 (M1 U1) In an equation for ‘from’: from Proxy = M1 (M1 U1) When typechecking the code for ‘from’ in a derived instance for ‘Generic (Proxy t)’: To see the code I am typechecking, use -ddump-deriv libraries/base/GHC/Generics.hs:826:1: error: Couldn't match type ‘M1 t0 t1 (M1 t3 t4 U1) t2’ with ‘M1 D x’ Expected type: Rep (Proxy t) x Actual type: M1 t0 t1 (M1 t3 t4 U1) t2 Relevant bindings include to :: Rep (Proxy t) x -> Proxy t (bound at libraries/base/GHC/Generics.hs:826:1) In the pattern: M1 (M1 U1) In an equation for ‘to’: to (M1 (M1 U1)) = Proxy When typechecking the code for ‘to’ in a derived instance for ‘Generic (Proxy t)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Generic (Proxy t)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8865: Cannot derive well-kinded instance of form ‘Category
by GHC 02 May '16

02 May '16

#8865: Cannot derive well-kinded instance of form ‘Category ----------------------------+---------------------------------------------- Reporter: | Owner: adinapoli | Status: new Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.8.1-rc2 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: GHC rejects valid program Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Hello everyone, sorry if this was already reported somewhere. I'm playing with GHC 7.8.1 RC2 and I'm updating hsenv to support GHC 7.8. This is a real code snippet, which was compiling fine in GHC 7.6.x {{{ newtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b) deriving (Category, Arrow, ArrowChoice) }}} but that yields the following in GHC 7.8.1-RC2 {{{ Cannot derive well-kinded instance of form ‘Category (ArgArrow ...)’ Class ‘Category’ expects an argument of kind ‘k -> k -> *’ In the newtype declaration for ‘ArgArrow’ }}} This might be related to the new feature of GHC 7.8, namely "kind variables" (you get the idea, even if the name is not 100% accurate). To make the code compile I had to enable {{{ StandaloneDeriving }}} and write the following: {{{ newtype ArgArrow a b = ArgArrow (StaticArrowT KnownArgs (Kleisli (ReaderT Args IO)) a b) deriving (Arrow, ArrowChoice) deriving instance Category ArgArrow }}} Is this by design or is a genuine bug? Thanks! Alfredo -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10266: Split base for Backpack
by GHC 02 May '16

02 May '16

#10266: Split base for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.11 libraries/base | Operating System: Unknown/Multiple Keywords: backpack | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let's resurrect #1338 and #1580. Our new concrete goal is to have users be able to replace 'base' with 'base-sig', which is some signature representing the modules from 'base' which we depend on. Since 'base' is a big, complicated package, the ability to specify subsets of 'base' is very useful: it can be used to define things like Haskell'98 base, base without any unsafe operations, etc. Right now, all wired in things live in ghc-prim (I believe). This is good, since we can't reasonably abstract wired in things away with a signature: GHC will always put them in some well-known place. However, this is not enough: there are many known-key/Rdr things the compiler knows about too, which need to be placed in specific package + module locations for GHC to be able to reference them; e.g. when deriving instances, etc. At the moment, most of these identifiers live in 'base', which is no good. So, here's the proposal: all non-rebindable GHC-known identifiers (as per PrelNames) should be moved to ghc-prim (or perhaps a new package? I don't really care either way) and reexported from the old packages which they were available from base. I'll try to work out in detail what moves, how to avoid orphan instances, etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10520: RecordWildCards causes “is not a (visible) field of constructor” in ghci
by GHC 02 May '16

02 May '16

#10520: RecordWildCards causes “is not a (visible) field of constructor” in ghci -------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux RecordWildCards | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ % ghc -ignore-dot-ghci -e 'data Foo = Bar { baz :: Integer } deriving Show' -e 'Bar 42' -e '(Bar 42){ baz = 43 }' -e 'Bar { baz = 42 }' Bar {baz = 42} Bar {baz = 43} Bar {baz = 42} }}} {{{ % ghc -ignore-dot-ghci -XRecordWildCards -e 'data Foo = Bar { baz :: Integer } deriving Show' -e 'Bar 42' -e '(Bar 42){ baz = 43 }' -e 'Bar { baz = 42 }' Bar {baz = 42} Bar {baz = 43} <interactive>:1:7: ‘baz’ is not a (visible) field of constructor ‘Bar’ }}} {{{ % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9758: By default, testsuite should clean up after successful tests
by GHC 30 Apr '16

30 Apr '16

#9758: By default, testsuite should clean up after successful tests -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A fully built GHC compiler for development takes about 1G of space. However, running the testsuite balloons this amount to 10G. Why? Because we don't clear away any test files by default. Now, it's pretty useful to have these files if you're debugging a problem. But I think it's pretty unnecessary for successful tests. So I suggest cleaning out the files automatically if the test succeeds. Tradeoff: the testsuite will take longer to run since it is cleaning up after itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9543: Testsuite driver: replace "extra_clean" by "git clean -X"
by GHC 26 Apr '16

26 Apr '16

#9543: Testsuite driver: replace "extra_clean" by "git clean -X" -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When adding a new test that creates extra files, one also has to do some bookkeeping: 1. Supply an `extra_clean` argument to the test function in `all.T`. 2. Add an entry in `testsuite/.gitignore` Step number 1 is often forgotten. Currently there are over 200 uncleaned files and directories left behind in the `testsuite`, after running `validate` and then `make clean` (checked with `git clean -X -d -n | wc -l`). I propose to replace the functionality that `extra_clean` provides, namely to remove these extra files when one calls `make clean`, by doing the equivalent of `git clean -X -d`: {{{ -X Remove only files ignored by Git. -d Remove untracked directories in addition to untracked files. ... }}} That is: use the information from the `.ignore` files to figure out which files to delete on `make clean`. The advantages of making this change are: 1. Less manual bookkeeping, less work, less code 2. A more thorough `make clean` Implementation detail: we can not just call `git clean` directly, since this should also work when we are not in a git directory (for example a build directory created with [wiki:Building/Using lndir]). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2