- ghc-tickets - Haskell.org

[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

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 30 Jun '17

30 Jun '17

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I do; it's been on my list for quite a while now. I'll kick off a build right now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13747: Can't use 'instance' keyword in associated type family instance
by GHC 30 Jun '17

30 Jun '17

#13747: Can't use 'instance' keyword in associated type family instance -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #associated-instances The manual on type families says:] > When an associated data or type synonym family instance is declared within a type class instance, we (optionally) may drop the instance keyword in the family instance" But that doesn't work for me. Using {{{ class Myclass a where type family MyFamily a :: * }}} then the code {{{ instance Myclass Mytype where type instance MyFamily Mytype = Int }}} doesn't compile but {{{ instance Myclass Mytype where type MyFamily Mytype = Int }}} I'd expect to be able to use the `instance` keyword here. I'd prefer this to be treated as an implementation bug instead of a doc bug, because I think it can be useful to be explicit for the ease of reading (and it work works the same way for class declaration, as the example also demonstrates). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13747> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 30 Jun '17

30 Jun '17

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Ben, there is a proposed patch upstream. Do you have the hardware to try it on? https://sourceware.org/bugzilla/show_bug.cgi?id=16177#c2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13886: GHC panic when using GHC plugins
by GHC 30 Jun '17

30 Jun '17

#13886: GHC panic when using GHC plugins -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm running GHC 8.0.2 on Windows 10. At first I was playing around with making my own type-checker plugin and I kept getting {{{#!hs ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. }}} on certain function calls (things like printing Docs). But now on an unrelated project I tried using the dump-core plugin and I'm getting the same error. The minimal example I can produce is simply {{{#!hs module Main where main = return () }}} compiled with `stack exec ghc -- -fplugin=DumpCore PluginTest.hs` (or I'm guessing equivalently `ghc -fplugin=DumpCore PluginTest.hs`) Make sure to install the dump-core package first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13886> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #8033: add AVX register support to llvm calling convention
by GHC 30 Jun '17

30 Jun '17

#8033: add AVX register support to llvm calling convention -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): See https://reviews.llvm.org/D34854. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8033#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException
by GHC 30 Jun '17

30 Jun '17

#13730: Running GLUT code in GHCi yields NSInternalInconsistencyException ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- I tried running some `GLUT` code in macOS Sierra (Version 10.12.5 (16F73)) and ran into a strange error. If you're willing to use `cabal-install`, you can just do this: {{{ $ cabal install GLFW-0.5.2.5 }}} And run this module in with `runghc`: {{{#!hs -- GLUT.hs module Main where import Graphics.UI.GLUT (($=), getArgsAndInitialize, createWindow, displayCallback, mainLoop) main :: IO () main = do (_progName, _args) <- getArgsAndInitialize _window <- createWindow "Hello World" displayCallback $= return () mainLoop }}} {{{ $ runghc GLUT.hs 2017-05-19 12:03:02.199 ghc[24628:669385] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread! }}} On the other hand, compiling and running the executable works without issue. Alternatively, you can compile the attached files, which require no dependencies: {{{ $ ghc HsGLUT.c GLUT2.hs [1 of 1] Compiling Main ( GLUT2.hs, GLUT2.o ) Linking GLUT2 ... $ ghci HsGLUT.o GLUT2.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rscott/.ghci [1 of 1] Compiling Main ( GLUT2.hs, interpreted ) Ok, modules loaded: Main. λ> main 2017-05-19 12:06:15.365 ghc[24671:670166] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread! }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12