January 2016 - ghc-tickets

Re: [GHC] #4471: Incorrect Unicode output on Windows Console
by GHC 09 Jan '16

09 Jan '16

#4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: Yet another release where this didn't happen. Due to the relatively small amount of activity on this ticket I'm going to reduce its priority. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4471#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

Re: [GHC] #314: #line pragmas not respected inside nested comments
by GHC 09 Jan '16

09 Jan '16

#314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't happen for 8.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/314#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 09 Jan '16

09 Jan '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: We likely won't make it to complete determinism for 8.0, sadly. Let's hope for 8.2! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11347: No skolem info: b_azg[sk]
by GHC 09 Jan '16

09 Jan '16

#11347: No skolem info: b_azg[sk] -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- I was testing this code, which is from our ICFP paper on Coercible: {{{#!hs {-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving, MultiParamTypeClasses, FlexibleInstances, AllowAmbiguousTypes #-} newtype Id1 a = MkId1 a newtype Id2 a = MkId2 (Id1 a) deriving (UnsafeCast b) type family Discern a b type instance Discern (Id1 a) b = a type instance Discern (Id2 a) b = b class UnsafeCast to from where unsafe :: from -> Discern from to instance UnsafeCast b (Id1 a) where unsafe (MkId1 x) = x unsafeCoerce :: a -> b unsafeCoerce x = unsafe (MkId2 (MkId1 x)) }}} without `AllowAmbiguousTypes` I get {{{ UnsafeCast.hs:11:3: error: Couldn't match type ‘Discern from to0’ with ‘Discern from to’ NB: ‘Discern’ is a type function, and may not be injective The type variable ‘to0’ is ambiguous Expected type: from -> Discern from to Actual type: from -> Discern from to0 In the ambiguity check for the type signature for ‘unsafe’: unsafe :: forall to from. UnsafeCast to from => from -> Discern from to To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: unsafe :: forall to from. UnsafeCast to from => from -> Discern from to In the class declaration for ‘UnsafeCast’ }}} (is that a bug? I feel like it could be, but I’m intimidated by the error message). So I put in the suggested pragma, and now I get {{{ UnsafeCast.hs:4:41: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151111 for x86_64-unknown-linux): No skolem info: b_azg[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is GHC-almost-HEAD (changeset:2f6e87/ghc). I’ll start a rebuild with head and see what has changed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #11336: GHC craches on this combination of ViewPatterns and PatternSynonyms
by GHC 09 Jan '16

09 Jan '16

#11336: GHC craches on this combination of ViewPatterns and PatternSynonyms -------------------------------------+------------------------------------- Reporter: baramoglo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached file crashes: {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Prelude.last: empty list }}} I wasn't able to shrink the example further despite many attepts. Tested on GHC 7.8.3 and 7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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