December 2015 - ghc-tickets

[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

[GHC] #11314: Documentation on const function is wrong
by GHC 09 Jan '16

09 Jan '16

#11314: Documentation on const function is wrong -------------------------------------+------------------------------------- Reporter: milleniumbug | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.10.3 libraries/base | 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: -------------------------------------+------------------------------------- It currently only says Constant function which is not only not informative (how am I supposed to use this function, some API examples would be nice), but actually wrong (`const` is not a constant function, `const x` is) I suggest the following wording instead: Returns a unary constant function (a function that returns the same value for all inputs) from the argument @a@. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11308: haddock and Cabal regression
by GHC 09 Jan '16

09 Jan '16

#11308: haddock and Cabal regression -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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: -------------------------------------+------------------------------------- Here's the bug: https://github.com/haskell/cabal/issues/3004 It's blocking on: https://github.com/haskell/haddock/issues/379 This ticket is to make sure we don't ship a buggy Cabal/haddock pair. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11268: Extend ghc environment file features
by GHC 09 Jan '16

09 Jan '16

#11268: Extend ghc environment file features -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D1668 | Wiki Page: -------------------------------------+------------------------------------- This is essential to make it into GHC 8.0.1 as it provides the infrastructure for cabal's new features See Phab:D1668 for more detail -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11268> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11304: GHC master segfaults when run with +RTS -h
by GHC 09 Jan '16

09 Jan '16

#11304: GHC master segfaults when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.11.20151218 $ ghc +RTS -h ghc: no input files Usage: For basic information, try the `--help' option. Segmentation fault }}} This appears to be due to ce1f1607ed7f8fedd2f63c8610cafefd59baaf32, {{{ commit ce1f1607ed7f8fedd2f63c8610cafefd59baaf32 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Sat Nov 7 09:39:05 2015 +0000 Make GHCi & TH work when the compiler is built with -prof }}} Which removes an `initProfiling2` call from `hs_init_ghc`, which means that `initHeapProfiling` is never called, which means that `censuses` is never initialized, which causes a crash during cleanup on RTS shutdown. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10337: One-shot module loops have hard to understand messages
by GHC 09 Jan '16

09 Jan '16

#10337: One-shot module loops have hard to understand messages -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider these two modules: {{{ -- A.hs module A where -- B.hs module B where import A }}} `ghc --make B.hs` will compile this fine. Now edit `A.hs` to be circular: {{{ -- A.hs module A where import B }}} and attempt to one-shot compile it with `ghc -c A.hs`. You will now get an uninformative error message: {{{ A.hs:1:1: Circular imports: module `A' depends on itself }}} You can get a more informative message with `--make`: {{{ Module imports form a cycle: module `A' (A.hs) imports `B' (./B.hs) which imports `A' (A.hs) }}} We should either suggest users try again with `--make`, or try harder to give a useful message in one-shot mode. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10362: Make tuple constraints into a class
by GHC 09 Jan '16

09 Jan '16

#10362: Make tuple constraints into a class -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment GHC treats tuple constraints specially. If you grep for `TuplePred` you'll see this. But the special treatment is strange; see the confusion between constraint tuples and ordinary tuples in #9858. But I now realise that we can sweep away all this nonsense. Suppose we declare {{{ module GHC.Classes where class (c1, c2) => (,) c1 c2 instance (c1, c2) => (,) c1 c2 class (c1, c2, c3) => (,) c1 c2 c3 instance (c1, c2, c3) => (,) c1 c2 c3 }}} and so on. (This is analogous the tuple data type declarations in `GHC.Tuple`.) Notice that: * `GHC.Classes,(,)` is a class, of kind `Constraint -> Constraint -> Constraint`. quite distinct from `GHC.Tuple.(,)`, whose kind is `* -> * -> *`. * `GHC.Classes.(,)` is a perfectly ordinary class, with no methods and two superclasses. * So all the usual superclass stuff applies. * If you have a given `Ord a` then you have a given `Eq a` (its superclass). Similarly if you have a given `(,) c1 c2` then you also have given `c1` and `given `c2`. * If you want to construct a dictionary of type `Ord a` (a "wanted"), you must supply a dictionary of type `Eq a`. Similarly, if you want to construct a dictionary of type `(,) c1 c2` then you must supply `c1` and `c2`. * I have written `(,) c1 c2` to stress that there is a class `GHC.Classes.(,)`, but we'll also allow the concrete syntax `(c1,c2)` instead. * Nevertheless the syntactic form `(c1, c2) => blah` is just sugar for `c1 => c2 => blah` (a type with two, curried constraints); it does not stand a type with a single constraint. Otherwise the instance {{{ instance (c1,c2) => (c1,c2) }}} would be the identity function! The key thing is that, aside from special syntax, `(,)` is a perfectly ordinary class, so we can simply delete all the special treatment of `TuplePred`. (Implicit parameters are also treated as a special class, incidentally.) There should be no user-visible effects. But I think it would cure the worst aspects of #10359, as well as cleaning up `TypeRep` confusion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2