August 2017 - ghc-tickets

[GHC] #14060: TH-reified types can suffer from kind signature oversaturation
by GHC 15 Aug '17

15 Aug '17

#14060: TH-reified types can suffer from kind signature oversaturation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | 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 ran into this issue when attempting to fix #11785 in `TcSplice`. Here's a simple Template Haskell program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Data.Proxy import Language.Haskell.TH newtype Foo = Foo (Proxy '[False, True, False]) $(return []) main :: IO () main = putStrLn $(reify ''Foo >>= stringE . pprint) }}} The output of this program is unfortunately noisy: {{{ $ runghc Bug.hs newtype Bug.Foo = Bug.Foo (Data.Proxy.Proxy ((':) 'GHC.Types.False ((':) 'GHC.Types.True ((':) 'GHC.Types.False ('[] :: [GHC.Types.Bool]) :: [GHC.Types.Bool]) :: [GHC.Types.Bool]) :: [GHC.Types.Bool])) }}} Somehow, we've ended up with four copies of a `[GHC.Types.Bool]` kind annotation! It definitely feels like Template Haskell could be more conservative here in choosing which types get explicit kind annotations - at the most, I'd only expect `'[]` to get one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13711: uname: illegal option -- o when running make clean in nofib
by GHC 15 Aug '17

15 Aug '17

#13711: uname: illegal option -- o when running make clean in nofib -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 8.0.1 benchmark suite | 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: -------------------------------------+------------------------------------- When running `make clean` in nofib, there are lots of warnings/errors like the following. I don't know if this is serious or not. I am on OS X. {{{ uname: illegal option -- o usage: uname [-amnprsv] rm -f Main.o *.CKP *.ln *.BAK *.bak .*.bak *.o core a.out errs ,* *.a .emacs_* tags TAGS *.ind *.ilg *.idx *.idx-prev *.aux *.aux-prev *.dvi *.log *.toc *.lot *.lof *.blg *.cb *_stub.c *_stub.h *.raw_s *.a.list a.out ./*.hi Main.hc reverse-complement Finished making clean in reverse-complement: 0 ------------------------------------------------------------------------ == /Applications/Xcode.app/Contents/Developer/usr/bin/make clean - --no- print-directory; in /Users/matt/Documents/haskell/ghc/nofib/shootout/spectral-norm ------------------------------------------------------------------------ uname: illegal option -- o usage: uname [-amnprsv] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13711> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14113: Error message carets point at the wrong places in the presence of CPP macros
by GHC 14 Aug '17

14 Aug '17

#14113: Error message carets point at the wrong places in the presence of CPP macros -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a program which doesn't typecheck: {{{#!hs {-# LANGUAGE CPP #-} module Bug where #define FOO putStrLn 4 main :: IO () main = FOO }}} The error message it gives looks kind of strange, however: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:17: error: • No instance for (Num String) arising from the literal ‘4’ • In the first argument of ‘putStrLn’, namely ‘4’ In the expression: putStrLn 4 In an equation for ‘main’: main = putStrLn 4 | 7 | main = FOO | ^ }}} That caret seems to be pointing as if `FOO` had been replaced by `putStrLn 4` in the diagnostic, but since it hadn't, it just points off into space. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14113> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14071: Porting GHC to Scheme without side-effecting
by GHC 14 Aug '17

14 Aug '17

#14071: Porting GHC to Scheme without side-effecting -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14108: GHCi doesn't remember let-less function declarations with -fobject-code
by GHC 14 Aug '17

14 Aug '17

#14108: GHCi doesn't remember let-less function declarations with -fobject-code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi supports two styles of function declaration: those using an explicit `let` keyword, and those without. This GHCi session demonstrates both: {{{ $ /opt/ghc/8.2.1/bin/ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/Documents/Hacking/Haskell/trifecta/.ghci Loaded GHCi configuration from /home/rgscott/.ghci λ> let foo1 :: Int; foo1 = 42 λ> foo1 42 λ> foo2 :: Int; foo2 = 42 λ> foo2 42 }}} But if using GHCi with the `-fobject-code` enabled, then the `let`-less style of declaration no longer works: {{{ $ /opt/ghc/8.2.1/bin/ghci -fobject-code GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/Documents/Hacking/Haskell/trifecta/.ghci Loaded GHCi configuration from /home/rgscott/.ghci λ> let foo1 :: Int; foo1 = 42 λ> foo1 42 λ> foo2 :: Int; foo2 = 42 λ> foo2 <interactive>:4:1: error: • Variable not in scope: foo2 • Perhaps you meant ‘foo1’ (line 1) }}} Originally noticed [https://github.com/ekmett/trifecta/pull/73#issuecomment-321829537 here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules
by GHC 13 Aug '17

13 Aug '17

#14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At time of writing master is at commit 14457cf6a50f708eecece8f286f08687791d51f7. In GhcMake.hs, both upsweep and parUpsweep call getModLoop for each module. getModLoop is (at least) linear when called on a .hs-boot ModSummary. See comments in Phab:3646. This isn't a big deal in practice, since .hs-boot modules are uncommon, but it does irk me, and it will be easy to fix. Fixing this would also be an opportunity to de-duplicate some logic in upsweep and parUpsweep. ccing niteria as he has worked with this code recently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14101: Type synonyms can make roles too conservative
by GHC 12 Aug '17

12 Aug '17

#14101: Type synonyms can make roles too conservative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- {{{#!hs import GHC.Exts type Arr# = Array# data Foo a = Foo (Arr# a) type role Foo representational }}} produces {{{ error: • Role mismatch on variable a: Annotation says representational but role nominal is required • while checking a role annotation for ‘Foo’ }}} If the type synonym is instead defined {{{#!hs type Arr# a = Array# a }}} then it works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13823: Use NonEmpty lists in more places in the GHC API
by GHC 12 Aug '17

12 Aug '17

#13823: Use NonEmpty lists in more places in the GHC API -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8782 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After GHC 8.2 is released and we drop support for building GHC with 7.10, we should try to use `Data.List.NonEmpty` in more places in the GHC API. I ran into this issue recently when using some functions from `ListSetOps`: {{{#!hs removeDups :: (a -> a -> Ordering) -> [a] -> ([a], [[a]]) findDupsEq :: (a -> a -> Bool) -> [a] -> [[a]] equivClasses :: (a -> a -> Ordering) -> [a] -> [[a]] }}} These type signatures are terrible. Really, they should be: {{{#!hs removeDups :: (a -> a -> Ordering) -> [a] -> ([a], [NonEmpty a]) findDupsEq :: (a -> a -> Bool) -> [a] -> [NonEmpty a] equivClasses :: (a -> a -> Ordering) -> [a] -> [NonEmpty a] }}} Since 90% of the time, the first thing you do after finding duplicates is to take a representative from the duplicate set. With lists, this requires the partial operation `head`, but with `NonEmpty`, this can be total like it was intended to be. I'm sure there are other places in the API that could benefit from `NonEmpty`, so if you have any suggestions, please leave them here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13823> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14094: DeriveAnyClass doesn't warn about unimplemented type families
by GHC 12 Aug '17

12 Aug '17

#14094: DeriveAnyClass doesn't warn about unimplemented type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall #-} module Bug where class C a where type T a data D a m :: a instance C Int deriving instance C Bool }}} Neither `C` instance implements any of its type families or methods. However, the manual `C Int` instance and the derived `C Bool` instance give different warnings: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:12:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘T’ • In the instance declaration for ‘C Int’ | 12 | instance C Int | ^^^^^^^^^^^^^^ Bug.hs:12:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘D’ • In the instance declaration for ‘C Int’ | 12 | instance C Int | ^^^^^^^^^^^^^^ Bug.hs:12:10: warning: [-Wmissing-methods] • No explicit implementation for ‘m’ • In the instance declaration for ‘C Int’ | 12 | instance C Int | ^^^^^ Bug.hs:13:1: warning: [-Wmissing-methods] • No explicit implementation for ‘m’ • In the instance declaration for ‘C Bool’ | 13 | deriving instance C Bool | ^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notice that the `C Int` instance warns about the lack of an implementation for `T` and `D`, as expected. However, the derived `C Bool` instance does not. It only warns about `m`! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14086: Empty case does not detect kinds
by GHC 12 Aug '17

12 Aug '17

#14086: Empty case does not detect kinds -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeInType, EmptyCase #-} module Silly where import Data.Kind f :: Type -> Int f x = case x of }}} GHC warns {{{ Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ :: * }}} In fact, `Type` is only a type because of `TypeInType`. It has no actual values, so the empty case is exhaustive. To be honest, I kind of wish GHC would give me a warning for doing something so silly as to even give a function an argument of type `Type`, but I imagine that might be hard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6