July 2017 - ghc-tickets

[GHC] #13905: ApplicativeDo is too strict with newtype patterns
by GHC 03 Jul '17

03 Jul '17

#13905: ApplicativeDo is too strict with newtype patterns -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- The fix to #13875 went a little too far, and interprets newtype constructor patterns as strict. It's not clear to me how to fix this, as the `Name` of the constructor doesn't seem to give any clue as to whether it is a newtype constructor or a data constructor. The comment at the top of `basicTypes/Name.hs` indicates {{{ -- * 'Name.Name' is the type of names that have had their scoping and binding resolved. They -- have an 'OccName.OccName' but also a 'Unique.Unique' that disambiguates Names that have -- the same 'OccName.OccName' and indeed is used for all 'Name.Name' comparison. Names -- also contain information about where they originated from, see "Name#name_sorts" }}} which suggests that this information should be available, but I don't know what's involved in propagating it to the right place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope"
by GHC 03 Jul '17

03 Jul '17

#13893: Improved Help for Control.Concurrent and Control.Exception when "variable not in scope" -------------------------------------+------------------------------------- Reporter: vanto | 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: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The piece of code that bgamari wrote in {{{#13891}}} is interesting from the point of view of the error messages.\\ {{{ main = do putStrLn "forking" forkIO $ bracket (putStrLn "forked") (const $ putStrLn "finalize") (const $ putStrLn "hello" >> threadDelay 100000000) threadDelay 10000 putStrLn "done" }}} When the imports are not written GHC answers.\\ {{{ Prelude> :l testfork [1 of 1] Compiling Main ( testfork.hs, interpreted ) testfork.hs:6:5: error: Variable not in scope: forkIO :: t0 -> IO a0 testfork.hs:6:14: error: Variable not in scope: bracket :: IO () -> (b1 -> IO ()) -> (b0 -> IO b2) -> t0 testfork.hs:6:101: error: Variable not in scope: threadDelay :: Integer -> IO b2 testfork.hs:7:5: error: Variable not in scope: threadDelay :: Integer -> IO a1 Failed, modules loaded: none. Prelude> }}} It would be advisable to complete by:\\ {{{Perhaps you intended to import Control.Concurrent}}} for {{{forkIO}}} and {{{threadDelay}}}.\\ {{{Perhaps you intended to import Control.Exception}}} for {{{bracket}}}.\\ I hope you have a way to write it once for all the variables involved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13893> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13912: Disparity in error message in GHCi with : load vs writing directly in GHCi
by GHC 02 Jul '17

02 Jul '17

#13912: Disparity in error message in GHCi with : load vs writing directly in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 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: -------------------------------------+------------------------------------- {{{ module Maintest where a:: Int a = 'a' main = print "b" }}} If I load this program with the command {{{:load}}} its answer is\\ {{{ Prelude> :l maintest [1 of 1] Compiling Maintest ( maintest.hs, interpreted ) maintest.hs:4:5: error: * Couldn't match expected type `Int' with actual type `Char' * In the expression: 'a' In an equation for `a': a = 'a' | 4 | a = 'a' | ^^^ Failed, modules loaded: none. Prelude> }}} If I write this program directly in GHCi, its answer is\\ {{{ Prelude> :{ Prelude| module Maintest where Prelude| a:: Int Prelude| a = 'a' Prelude| main = print "b" Prelude| :} <interactive>:20:5: error: * Couldn't match expected type `Int' with actual type `Char' * In the expression: 'a' In an equation for `a': a = 'a' Prelude> }}} This information has disappeared\\ {{{ | 4 | a = 'a' | ^^^ }}} The version of GHCi used is this one {{{GHCi, version 8.2.0.20170507}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13907: stack upgrade fails on Mac OS
by GHC 01 Jul '17

01 Jul '17

#13907: stack upgrade fails on Mac OS -------------------------------------+------------------------------------- Reporter: gukoff | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- Configuring stack-1.4.0... stack-1.4.0: build Preprocessing library stack-1.4.0... [ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o ) [ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 8 of 124] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/tj/sfwy4my94nvdn8qx3l2cd97n_75vlr/T/ghc78750_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/tj/sfwy4my94nvdn8qx3l2cd97n_75vlr/T/ghc78750_0/libghc_68.dylib: malformed mach-o: load commands size (49568) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 26 action(s). -- While building package stack-1.4.0 using: /private/var/folders/tj/sfwy4my94nvdn8qx3l2cd97n_75vlr/T/stack- upgrade75916/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym
by GHC 01 Jul '17

01 Jul '17

#12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Inspired by the recent Ghostbuster paper http://www.cs.ox.ac.uk/people/timothy.zakian/ghostbuster.pdf , I was experimenting with using pattern synonyms to simulate GADTs. In the process, I noticed that we should be able to generalize the implicit bidirectional synonyms to allow constructors on the LHS. Consider this program: {{{ {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fwarn-incomplete-patterns #-} module GhostBuster where import GHC.TypeLits newtype Vec a (n :: Nat) = Vec { unVec :: [a] } pattern VNil :: Vec a 0 pattern VNil = Vec [] pattern VCons :: a -> Vec a n -> Vec a (n + 1) pattern VCons x xs <- Vec (x : (Vec -> xs)) where VCons x (Vec xs) = Vec (x : xs) headVec :: Vec a (n + 1) -> a headVec (VCons x _) = x }}} In effect, we simulate a vector GADT using pattern synonyms to handle the newtype `Vec`. I would like it if I could specify the `VCons` pattern more simply, as just: {{{ pattern VCons :: a -> Vec a n -> Vec a (n + 1) pattern VCons x (Vec xs) = Vec (x : xs) }}} And GHC would infer the correct pattern (the constructor can be read off immediately), automatically replacing occurrences of `xs` with a view pattern that reconstructs the constructors that were stripped off on the LHS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13670: Improving Type Error Messages
by GHC 01 Jul '17

01 Jul '17

#13670: Improving Type Error Messages -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- I was reading through https://medium.com/@sjsyrek/some-notes-on-haskell- pedagogy-de43281b1a5c the other day, and noticed a pretty gnarly error message produced by the following code {{{ {-# LANGUAGE InstanceSigs #-} data List a = EmptyList | ListElement a (List a) deriving Show instance Functor List where fmap :: (a -> b) -> List a -> List b fmap f xs = ListElement (f x) xs }}} {{{ list.hs:8:49: error: • Couldn't match type ‘a’ with ‘b’ ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 Expected type: List b Actual type: List a • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3) }}} I think there are a few things we could do better here. 1. The biggest issue IMO is that the key piece of information, the mismatch between `List a` and `List b` is stuck right in the middle of the error message, obscured by GHC's attempt to be helpful by pointing out the provenance of `a` and `b`. The mismatch should be front and center, so users see it without having to dig through a wall of text! I think just swapping the order of the expected/actual types and the tyvar provenance would be a big improvement. {{{ list.hs:8:49: error: • Couldn't match type ‘a’ with ‘b’ Expected type: List b Actual type: List a ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b at list.hs:7:11 • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3) }}} But there's more we can do! 2. The rust compiler does this very nice thing where it attaches helpful notes that relate to the error to other source spans. The benefit here is that editors can then '''highlight''' multiple spans to produce a nicer visual. In our case, the provenance of the tyvars feels like such a helpful note, rather than a core part of the error message. {{{ list.hs:8:49: error: • Couldn't match type ‘a’ with ‘b’ Expected type: List b Actual type: List a • In the second argument of ‘ListElement’, namely ‘xs’ In the expression: ListElement (f x) xs In an equation for ‘fmap’: fmap f (ListElement x xs) = ListElement (f x) xs • Relevant bindings include xs :: List a (bound at list.hs:8:25) x :: a (bound at list.hs:8:23) f :: a -> b (bound at list.hs:8:8) fmap :: (a -> b) -> List a -> List b (bound at list.hs:8:3) list.hs:7:11: note: • ‘a’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b list.hs:7:11: note: • ‘b’ is a rigid type variable bound by the type signature for: fmap :: forall a b. (a -> b) -> List a -> List b }}} Now the editor will highlight the ill-typed `xs` in red, with a popup that just provides the error; and the type for `fmap` in another color (usually blue it seems), with a popup that explains the provenance of the tyvars. (We might also want to separate the "relevant bindings" into a helpful note.) I believe many linter packages for editors are already setup to distinguish between errors and helpful notes, so this would be a really simple and free improvement. 3. Finally, I've always liked how GHC helpfully explains the context in which the error occurs ("in the second argument ... in the expression ... etc"), but I think we've been outclassed by other compilers that just print the offending line with the error underlined. We could adopt this strategy. (Related: it seems redundant to provide this context if the user is inside their editor rather than at the command-line. What if we had a flag `--editor-mode` to prune such redundancies?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 01 Jul '17

01 Jul '17

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Changes (by winter): * cc: winter (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0