September 2016 - ghc-tickets

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 04 Sep '16

04 Sep '16

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => bollu -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10161: GHC does not relink if a library's code changed
by GHC 03 Sep '16

03 Sep '16

#10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Test case for reproducing: https://github.com/nh2/ghc-relinking-avoidance- bug/ ---- {{{myexe}}} is an executable that depends on {{{mylib}}}, whose {{{myfun = putStrLn "output 1"}}}. If we install {{{mylib}}}, compile {{{myexe}}}, then change mylib's code to {{{myfun = putStrLn "output 2"}}}, re-install it, and then compile {{{myexe}}}, then GHC does not notice that the library code changed. It avoids re-linking myexe, with the result that the program prints {{{output 1}}} when you told it to compile against code that prints {{{output 2}}}. ---- Note that I had to use {{{NOINLINE myfun}}} to trigger the bug, since otherwise {{{myfun}}}'s code would have ended up in the interface file, thus changing the package ID, which naturally forces GHC to relink (even re-compile). With the {{{NOINLINE}}}, the package IDs of the two different versions of {{{myfun}}} are completely identical. I think that is correct, since the package ID only hashes the API and ABI, not the actual implementation, right? How does GHC decide when to relink? I think in the present case, it doesn't notice that the object/archive file of the library changed. Does it check that somehow? Just looking at API and API can't be enough to make a decision for linking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11565: Restore code to handle '-fmax-worker-args' flag
by GHC 03 Sep '16

03 Sep '16

#11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 i had a pass through DynFlags I've noticed dead code: https://phabricator.haskell.org/D1727 It was accidentally lost 3 years ago in major update changeset:0831a12ea2fc73c33652eeec1adc79fa19700578 The consensus is to try to put option handling back. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11565> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10923: GHC should recompile if flags change
by GHC 03 Sep '16

03 Sep '16

#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Example: {{{ ezyang@sabre:~$ rm B.hi ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs -O compilation IS NOT required }}} Pretty minor, but would be nice to have fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12557: Regression in type inference with RankNTypes
by GHC 03 Sep '16

03 Sep '16

#12557: Regression in type inference with RankNTypes -------------------------------------+------------------------------------- Reporter: slindley | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs foo :: ((forall a.f a) -> f r) -> f r foo g = undefined }}} In GHC 7.10.3: {{{ *Main> :t \g -> foo g \g -> foo g :: ((forall a. f a) -> f r) -> f r }}} In GHC 8.0.1: {{{ *Main> :t \g -> foo g <interactive>:1:11: error: • Couldn't match expected type ‘(forall a. f a) -> f r’ with actual type ‘t’ ‘t’ is a rigid type variable bound by the inferred type of it :: t -> f r at <interactive>:1:1 • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: t (bound at <interactive>:1:2) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11740: RFC kind synonyms
by GHC 03 Sep '16

03 Sep '16

#11740: RFC kind synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Are any of these useful now that we have kind synonyms: {{{#!hs -- Control.Category type Cat k = k -> k -> Type -- Data.Kind type Kind = Type type Types = [Type] type TypeClass = Type -> Constraint }}} `Cat` is not limited to `Control.Category` but applies in all [https://github.com/ekmett/hask/blob/master/src/Hask/Category.hs#L68 hask], [https://github.com/mikeizbicki/subhask/blob/b5433b959914d8214bcc4f130ff1b3d… subhask] and is defined by [https://github.com/ttuegel/recategorize/blob/master/src/Category/Category.h… recategorize]. It lets you rewrite: {{{#!hs -- newtype Yoneda (p :: i -> i -> *) (a :: i) (b :: i) = Op { getOp :: p b a } newtype Yoneda :: Cat i -> Cat i where Op :: { getOp :: p b a } -> Yoneda p a b -- type family Op (p :: i -> i -> *) :: i -> i -> * where type family Op (p :: Cat i) :: Cat i where Op (Yoneda p) = p Op p = Yoneda p -- data CatT (cat :: * -> * -> *) (a :: k) (b :: k) (cat1 :: k -> k -> *) (cat2 :: k -> k -> *) data CatT (cat :: Cat Type) (a :: k) (b :: k) (cat1 :: Cat k) (cat2 :: Cat k) -- class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where -- type Dom f :: i -> i -> * -- type Cod f :: j -> j -> * class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where type Dom f :: Cat i type Cod f :: Cat j -- data Nat (p :: i -> i -> *) (q :: j -> j -> *) (f :: i -> j) (g :: i -> j) where data Nat (p :: Cat i) (q :: Cat j) (f :: i -> j) (g :: i -> j) where -- instance Cartesian ((->) :: * -> * -> *) where instance Cartesian ((->) :: Cat Type) where }}} and {{{#!hs -- class (f x, g x) => And (f :: * -> Constraint) (g :: * -> Constraint) (x :: *) -- instance (f x, g x) => And (f :: * -> Constraint) (g :: * -> Constraint) (x :: *) class (f x, g x) => And (f :: TypeClass) (g :: TypeClass) (x :: *) instance (f x, g x) => And (f :: TypeClass) (g :: TypeClass) (x :: *) -- ToContext (fs :: [TypeClass]) :: TypeClass where type family ToContext (fs :: [* -> Constraint]) :: * -> Constraint where ToContext (f:g:fs) = And f (ToContext (g:fs)) ToContext '[f] = f }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12561: Scope extrusion in Template Haskell
by GHC 02 Sep '16

02 Sep '16

#12561: Scope extrusion in Template Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With typed quotes `[|| e ||]` and splices `$$(e)`, Template Haskell is supposed guarantee to generate type-correct code. But a conversation with Oleg following my talk at the Cambridge Metaprogramming Summer School (Aug 16) made me realise that it isn't. The problem is that {{{ [|| e ||] :: Q (TExp ty) }}} So a typed quote is still monadic. That is useful because it means that a function returning code can fail gracefully: {{{ f :: Int -> Q (TExp Bool) f n | n < 0 = fail "Argument less than zero" | otherwise = .... }}} yielding a civilised error in the type checker's monad. But giving ALL the power of Q is too much. Below is a program cooked up by Oleg that demonstrates the problem concretely. {{{ {-# Language TemplateHaskell #-} module T where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Language.Haskell.TH.Ppr import Data.IORef show_code cde = (runQ . unTypeQ $ cde) >>= putStrLn . pprint t1 = do c1 <- [|| (1::Int) + 2 ||] c2 <- [|| 3 + $$(return c1) ||] return c2 t2 :: Q (TExp Int) t2 = do r <- runIO $ newIORef undefined c1 <- [|| \x -> (1::Int) + $$(do xv <- [||x||] runIO $ writeIORef r xv return xv) ||] runIO $ readIORef r t1s = show_code t1 ts2 = show_code t2 }}} ----------------------- Possible solutions. * Give typed quotes access to only an emasculated Q monad, thus {{{ [[| e ||] :: QQ (TExp ty) }}} where `QQ` has more limited effects. This would work, and has the merit of simplicity. We can read stuff (reification), report errors, and even catch those exceptions -- provided that we don't include `TExp` values in exceptions (not sure how we prevent that!). * Do what Meta OCaml does. Oleg writes "But you can go all the way and allow any effects. Q becomes no special (and possibly redundant). The stress is not on precluding scope extrusion statically but catch it immediately when it occurs (and report it with detailed error information: which variable has escaped, on which line of the source code was its intended binder, etc). This is what MetaOCaml does. I should stress it reports the scope extrusion even for open code, if one (of many) free variables in that code cannot eventually be bound. So the problem is not a scope extrusion per se: it is waiting until the whole code is generated to report it, at which time lots of information is already lost and it becomes very difficult to find the error. But reporting the error requires quite a bit of internal changes, to track free variables in any TH code fragment. Anyway, if you want to write the Wiki page, you can refer to my BER MetaOCaml paper, which describes the process." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers
by GHC 02 Sep '16

02 Sep '16

#12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we have in a file: {{{#!hs data X = X String unX (X s) = s }}} And then load the file in ghci with `-fobject-code` and {{{ > data Y = Y String > unX (Unsafe.Coerce.unsafeCoerce (Y "foo")) "Segmentation fault (core dumped) }}} Even though we are shooting ourselves in the foot there, the constructors `X` and `Y` are represented identically internally, so the code is supposed to work. And it does work if we either move `unX` into ghci'd code, or `Y` into compiled code. After a legthy debugging session with @rwbarton over IRC, we've identified the culprit of this. As [[Commentary/Rts/HaskellExecution/PointerTagging]] states, "In the continuation of an algebraic case, R1 is assumed tagged". And all compiled constructors tag the pointer when entered, e.g: {{{ Dump of assembler code for function ghczmprim_GHCziTypes_False_static_info: 0x00007fffef8dd018 <+0>: 48 ff c3 inc %rbx 0x00007fffef8dd01b <+3>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function base_GHCziBase_Just_static_info: 0x00007ffff03eb780 <+0>: 48 83 c3 02 add $0x2,%rbx 0x00007ffff03eb784 <+4>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function ghczmprim_GHCziTypes_GT_static_info: 0x00007fffef8dd1f8 <+0>: 48 83 c3 03 add $0x3,%rbx 0x00007fffef8dd1fc <+4>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function base_GHCziRTSziFlags_HeapByClosureType_static_info: 0x00007ffff057e768 <+0>: 48 ff c3 inc %rbx // more than 7 constructors so all tags are '1' 0x00007ffff057e76b <+3>: ff 65 00 jmpq *0x0(%rbp) }}} Whereas all ghci-bound data constructors share the `stg_interp_constr_entry` entry code (with an optional trampoline leading there): {{{ Dump of assembler code from 0x7ffff7ff3080 to 0x7ffff7ff3090: => 0x00007ffff7ff3080: jmpq *0x2(%rip) # 0x7ffff7ff3088 0x00007ffff7ff3088: 0x00007fffef4c9388 Dump of assembler code for function stg_interp_constr_entry: 0x00007fffef4c9388 <+0>: ff 65 00 jmpq *0x0(%rbp) }}} Relevant code: source:libraries/ghci/GHCi/InfoTable.hsc#L32 So in the end, compiled code relies on the assumption that the pointer is tagged, and ghci constructors produce untagged pointers. Even though it is currently impossible to have compiled code pattern match on a ghci constructor, I think this shouldn't happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write"
by GHC 02 Sep '16

02 Sep '16

#12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tests `ffi017` and `ffi021` are failing on Windows, for `WAY=ghci`. > During interactive linking, GHCi couldn't find the following symbol: > lseek > During interactive linking, GHCi couldn't find the following symbol: > write These are regressions from 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs
by GHC 02 Sep '16

02 Sep '16

#12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs ------------------------------+--------------------------------- Reporter: pl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+--------------------------------- GHCi (win32, v8.0.1) gives strange unknown symbols when being run using a library that interfaces code written in C or C++. Compiled code runs fine. As an example I use the eigen-2.1.6 package from hackage. However, it should be noted that I get a similar error message when trying to link a package that uses libgsl (gsl has been compiled with the mingw-gcc that ships with haskell-platform). When I compile the little script from the eigen-manual on hackage {{{#!hs module Main where import Data.Eigen.Matrix import Data.Eigen.LA main = do let a :: MatrixXd a = fromList [[1,2,3], [4,5,6], [7,8,10]] b = fromList [[3],[3],[4]] x = solve ColPivHouseholderQR a b putStrLn "Here is the matrix A:" >> print a putStrLn "Here is the vector b:" >> print b putStrLn "The solution is:" >> print x }}} I get (as expected): {{{ Here is the matrix A: Matrix 3x3 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 10.0 Here is the vector b: Matrix 3x1 3.0 3.0 4.0 The solution is: Matrix 3x1 -2.0 1.0000000000000016 0.9999999999999988 }}} However, when I try to run it in GHCi I get {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> main ghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown symbol `___emutls_get_address' ghc.exe: Could not on-demand load symbol '___cxa_get_globals' ghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown symbol `___cxa_get_globals' ghc.exe: Could not on-demand load symbol '___cxa_begin_catch' ghc.exe: D:\Users\U439644\AppData\Roaming\cabal\i386-windows- ghc-8.0.1\eigen-2.1.6-6ZlfU8NIal9qgw3j5GclW\HSeigen-2.1.6-6 ZlfU8NIal9qgw3j5GclW.o: unknown symbol `___cxa_begin_catch' ghc.exe: unable to load package `eigen-2.1.6' }}} I tried the same on OS X using GHCi v8.0.1. There everything works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12496> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4