October 2015 - ghc-tickets

[GHC] #10968: Type hole cause bad type checking
by GHC 12 Jan '16

12 Jan '16

#10968: Type hole cause bad type checking -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: bug | Status: new Priority: normal | 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): | Wiki Page: -------------------------------------+------------------------------------- I've tried to compile that incorrect code on ghc-7.10.2 linux x86_64: {{{#!hs import Control.Monad.Reader type Tst m = ReaderT () (ReaderT Int m) f :: Monad m => Tst m () f = return () f1 :: ReaderT () m () -> ReaderT () m () f1 ev = f >> _ >> ev main :: IO () main = print $ runReaderT (f1 (return ())) () }}} But тypechecker does not reject f1 and have that: {{{ [1 of 1] Compiling Main ( /home/ndtimofeev/tst.hs, /home/ndtimofeev/tst.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): StgCmmEnv: variable not found $dFunctor_aYS local binds for: f_rsZ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If switch hole to undefined, i have normal typechecking error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10719: Malformed data type quotation accepted
by GHC 11 Jan '16

11 Jan '16

#10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This is accepted: Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A where C :: C |])}}} "[DataD [] A_1627402878 [] [ForallC [] [] (NormalC C_1627402879 [])] []]" In contrast this is rejected: Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A p where C :: C |])}}} <interactive>:29:22: Malformed constructor result type: C However it would make sense to form an equality constraint (for later kind/type checking) in these cases, something along the lines of: {{{#!hs data A p where C :: (A p ~ C) => C }}} as there could be type synonym (or family) `C`. I have tested various versions >= 7.8.3 and all seem to behave the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10476: Wrong ar during cross-compilation
by GHC 10 Jan '16

10 Jan '16

#10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: cross- | Type of failure: Building GHC compiling | failed Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It appears that during cross-compilation, while building stage 1 ghc, the build system uses ar for target architecture instead of ar for build/host architecture. It will cause linking errors on systems where ar for target architecture is incompatible with ar for build/host architecture (sample output attached below). {{{ (...) "rm" -f libraries/Cabal/Cabal/dist- boot/build/libHSCabal-1.22.3.0-3tdTeip89ooLNDDdwdA54s.a.contents "rm" -f libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a libraries/bin-package-db/dist- boot/build/libHSbin-package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents echo libraries/bin-package-db/dist-boot/build/GHC/PackageDb.o >> libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents "/Users/jakub/src/haskell/PNaCl/gsoc/wrappers/i686-unknown-nacl-ar" q libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a @libraries/bin-package-db/dist- boot/build/libHSbin-package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents /Users/jakub/src/nacl_sdk/pepper_canary/toolchain/mac_x86_newlib/bin/i686 -nacl-ar: creating libraries/bin-package-db/dist-boot/build/libHSbin- package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a "rm" -f libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents (...) ld: archive has no table of contents file '/Users/jakub/src/haskell/PNaCl /ghc-pnacl/libraries/terminfo/dist- boot/build/libHSterminfo-0.4.0.1-7qZwBlx3clR8sTBilJl253.a' for architecture x86_64 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10776: DataKinds promotion of String -> Symbol and Natural -> Nat
by GHC 10 Jan '16

10 Jan '16

#10776: DataKinds promotion of String -> Symbol and Natural -> Nat -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: DataKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Exactly what it says on the tin. It would be nice if the following would compile: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs #-} import GHC.TypeLits import GHC.Natural data X = X String Natural data Y :: X -> * where Y :: Y (X "hello" 4) }}} I kind of assume there's already a ticket for this, but couldn't find one, so figured I'd open one in case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to <Shlobj.h>
by GHC 09 Jan '16

09 Jan '16

#10273: haskeline : Cross-compile from Linux to Windows fails due to <Shlobj.h> -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries | Version: 7.11 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #10070 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The #include of <Shlobj.h> doesn't work when cross-compiling from Linux to Windows because the Linux file system is case sensitive and on Linux the file is <shlobj.h>. Down casing the name of this include file should not cause problems on Windows as the Windows file system is case insensitive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10273> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10703: -fth-dec-file can't handle lambdas
by GHC 09 Jan '16

09 Jan '16

#10703: -fth-dec-file can't handle lambdas -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10701 Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs instance Data.TH.Object.Object InputDropboxFiles String Language.JavaScript.Interpret.Primitive where toObject x@(InputDropboxFiles {}) = fromList (Data.Maybe.catMaybes [Just (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) "root" (inputDropboxFilesRoot x)), Just (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) "path" (inputDropboxFilesPath x)), fmap (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) "rev") (inputDropboxFilesRev x), Just (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) "access_token" (inputDropboxFilesAccess_token x))]) }}} {{{#!hs (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr)) "root" (inputDropboxFilesRoot x) }}} should be {{{#!hs ((\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr))) "root" (inputDropboxFilesRoot x) }}} ie. the lambda needs parentheses around it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10603: Output of -ddump-splices is parenthesized incorrectly
by GHC 09 Jan '16

09 Jan '16

#10603: Output of -ddump-splices is parenthesized incorrectly -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: Other Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Sometimes, Template Haskell splices lack necessary parentheses. Minimal example: {{{ $ ghci -XTemplateHaskell -ddump-splices GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help λ> :t $([| case Just 'a' of Just a -> Just ((\x -> x) a) |]) <interactive>:1:3-53: Splicing expression [| case Just 'a' of { Just a_avZ -> Just ((\ x_aw0 -> x_aw0) a_avZ) } |] ======> case Just 'a' of { Just a_a3wI -> Just (\ x_a3wJ -> x_a3wJ a_a3wI) } $([| case Just 'a' of Just a -> Just ((\x -> x) a) |]) :: Maybe Char }}} The suspect part is {{{case Just 'a' of { Just a_a3wI -> Just (\ x_a3wJ -> x_a3wJ a_a3wI) } }}}, which should be {{{case Just 'a' of { Just a_a3wI -> Just ((\ x_a3wJ -> x_a3wJ) a_a3wI) } }}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10603> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8736: GHCi doesn't load .dyn_o files appropriately
by GHC 09 Jan '16

09 Jan '16

#8736: GHCi doesn't load .dyn_o files appropriately ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Now that GHCi generally defaults to dynamic linking, it handles dynamic object files. But it doesn't implicitly handle the `-dynamic-too` case appropriately: {{{ $ cat Test.hs main = return () $ ./inplace/bin/ghc-stage2 -dynamic Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> ^D $ ./inplace/bin/ghc-stage2 -dynamic-too Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Test.hs, interpreted ) Ok, modules loaded: Main. *Main> }}} Also: {{{ $ ./inplace/bin/ghc-stage2 --interactive Test.dyn_o GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Warning: ignoring unrecognised input `Test.dyn_o' Prelude> }}} but it does handle the `.o` case. This should all be fixed and merged to 7.8 since it'll likely be very annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10663: ghci ignores stuff after an import command and a semicolon
by GHC 09 Jan '16

09 Jan '16

#10663: ghci ignores stuff after an import command and a semicolon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I can put a semicolon and then an expression or declaration after an import command in ghci, and the expression or declaration is simply ignored. {{{ rwbarton@morphism:~/ghc$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> import Data.List; x Prelude Data.List> }}} The stuff after the semicolon does have to parse, but then is discarded. Pretty confusing. It's especially confusing when using `ghc -e` {{{ rwbarton@morphism:~/ghc$ ghc-7.10.1 -e "import Data.List; sort [2,1]" rwbarton@morphism:~/ghc$ echo $? 0 }}} The command is wrong (in general you cannot give multiple commands separated by semicolons, you must use multiple `-e` options), but GHC fails to complain in any way and silently ignores the "second command". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8793: Improve GHC.Event.IntTable performance
by GHC 09 Jan '16

09 Jan '16

#8793: Improve GHC.Event.IntTable performance ------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The performance of `GHC.Event.IntTable` can be improved. I've managed to get some nice increases across the board. Benchmarking using `criterion` shows: function, % faster than current impl. `insert`: 4% `lookup`: 26% `update`: 11% `delete`: 5% There is one strange thing I noted. In `updateWith`, there is an inner loop that looks like this: {{{ data Bucket a = Empty | Bucket Int a (Bucket a) go _ Empty = (False, Nothing, Empty) go cont (Bucket key val next) | key == k = case f val of Nothing -> (True, Just val, cont next) Just v -> (False, Just val, cont (Bucket key v next)) | otherwise = go (\x -> cont (Bucket key val x)) next }}} which returns a tuple that is immediately consumed like so: {{{ (delete_occurred, old_val, new_bkt) <- go id ... when (isJust old_val) $ do <updateIntTable> when delete_occurred <decIntTableSize> return old_val }}} I expected that inlining the `<updateIntTable>` and `<decIntTableSize>` code blocks directly into `go` would result in better code than creating a tuple and then pattern matching on it afterwards. ie. {{{ go _ Empty = return Nothing go cont (Bucket key val next) | key == k = do case f val of Nothing -> <updateIntTable> (cont next) >> <decIntTableSize> Just v -> <updateIntTable> (cont (Bucket key v next) return (Just val) | otherwise = go (\x -> cont (Bucket key val x)) next }}} which has the exact same semantics. To my suprise, this code is almost 2x slower! The core generated in both cases is exactly what I'd expect; if anything, the second version seems tighter. I'm not sure why the first version is faster, but perhaps the original author, Bryan O'Sullivan, can shed some light as he used the tupled method in the first version. I'll attach my patch, `criterion`'s html output for the benchmarks as well as the benchmarking code, and the core for the oddity I discussed above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23