August 2018 - ghc-tickets

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 20 Aug '18

20 Aug '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * milestone: => 8.8.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15295: Haddock options should be concatened
by GHC 20 Aug '18

20 Aug '18

#15295: Haddock options should be concatened -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: haddock | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we have the following situation: 1. If we have an `OPTIONS_HADDOCK` pragma, any CLI options from `-haddock- opts` are ignored 2. If there are multiple `OPTIONS_HADDOCK` pragmas, only the last one is remembered. Instead all options should be concatenated (with `, `), with the CLI options at the end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors.
by GHC 20 Aug '18

20 Aug '18

#15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. -------------------------------------+------------------------------------- Reporter: Wizek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Me and Neil Mitchell have ran into this quite a few times while using GHCid, here is our discussion: https://github.com/ndmitchell/ghcid/issues/159 Here is a small reproducible example: {{{#!hs module Main where foo :: String foo = show a where a = baz bar :: Int bar = 1 main = putStrLn foo }}} GHC 8.0.x and above will say {{{ src/Main.hs:4:7: error: • Ambiguous type variable ‘a0’ arising from a use of ‘show’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance (Show a, Show b) => Show (Either a b) -- Defined in ‘Data.Either’ instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ ...plus 23 others ...plus 212 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: show a In an equation for ‘foo’: foo = show a where a = baz | 4 | foo = show a | ^^^^^^ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ }}} It's much more useful and much less noisy what 7.10.3 reports: {{{ src/Main.hs:5:13: Not in scope: ‘baz’ Perhaps you meant ‘bar’ (line 8) }}} So a desired output would be something like this for a later GHC release: {{{ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ }}} Or if someone is adamant about keeping the other errors even when there are out of scope variables present, then at least can we please reorder them such that the much more relevant out-of-scope errors are at the top? {{{ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ src/Main.hs:4:7: error: • Ambiguous type variable ‘a0’ arising from a use of ‘show’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance (Show a, Show b) => Show (Either a b) -- Defined in ‘Data.Either’ instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ ...plus 23 others ...plus 212 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: show a In an equation for ‘foo’: foo = show a where a = baz | 4 | foo = show a | ^^^^^^ }}} I might even be up for fixing this if there is agreement on the next steps to be taken. (Though I've never contributed to GHC before, on the surface this doesn't seem hard to fix.) What do you think? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12482: Infinite compilation time when using wrongly ordered constraints
by GHC 20 Aug '18

20 Aug '18

#12482: Infinite compilation time when using wrongly ordered constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello guys! I've seen today a very strange bug in GHC 8. Namely I've got an instance: {{{ instance {-# OVERLAPPABLE #-} (PrimMonad m, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m, HasProperty2' t g) => DynamicM t (HMGraph s rels) m a where addM el = nested (prop2' @t . wrapped') $ (swap ∘ fmap Ptr) <∘> ixed Cont.addM (unsafeCoerce el) }}} and I'm using it indirectly in Main.hs. It compiles fast and works fine. The problem is that when I change the above constraint to: {{{ (PrimMonad m, HasProperty2' t g, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m) }}} Which is basically the same but with different order, the file with this constraint compiles fast and fine, but Main.hs compiles infinite amount of time (I've killed it after 10 minutes). The problem is reproducible, but it is hard right now to make minimal example out of it (we are going to a conference with a product release and we cannot track it right now). I post it here because maybe the bug is known, if not, after the release I'll try to provide more info. If you've got any questions I'd love to assist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15542: DuplicateRecordFields not honored within a data family?
by GHC 20 Aug '18

20 Aug '18

#15542: DuplicateRecordFields not honored within a data family? -------------------------------------+------------------------------------- Reporter: michalrus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I’m observing some weird behavior, which is probably closely related to issue #15149. The following minimized code does not compile on 8.2.1, 8.2.2, but it does compile on 8.4.3. However, in my original (non-free) codebase, this is reversed: 8.2.2 compiles it just fine, and 8.4.3 fails with both errors per usage location at the same time: {{{ src/.../Docs.hs:123:11: error: • Constructor ‘X'Y’ does not have the required strict field(s): z ... src/.../Docs.hs:123:11: error: • Constructor ‘X'Y’ does not have field ‘z’ }}} I noticed, after updating the codebase’s compiler to 8.4.3. If the `z` field is renamed and unique, it compiles correctly. How can I go about debugging/minimizing this? This is the minimized code that works the other way round (OK on 8.4.3, fails on 8.2.2): {{{#!hs {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE StrictData #-} module Main where data AB = A | B class SomeClass (ab :: AB) where data SomeData ab instance SomeClass 'A where data SomeData 'A = SomeData'A{someField :: Int} deriving Show instance SomeClass 'B where data SomeData 'B = SomeData'B{someField :: Int} main :: IO () main = print SomeData'A{someField = 5} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15220: ScopedTypeVariables binds a non-existent variable
by GHC 20 Aug '18

20 Aug '18

#15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- GHC accepts this definition: {{{#!hs f :: (forall a. a -> a) -> () f (x :: b -> b) = x (undefined :: b) `seq` () }}} If a scoped type variable is bound always to a variable, then what variable is `b` bound to? In the desugared Core, it looks like `b` is bound to `Any`. Note that I couldn't find any valid argument for `x` here other than `undefined`. I think this definition should be rejected. In terms of implementation, the `zonkTcTypeToType` function should never encounter a unfilled-in `SigTv`. If it does, error. I don't like putting the error there, but I'm not sure I know another place to do it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11394: Base should use native Win32 IO on Windows
by GHC 20 Aug '18

20 Aug '18

#11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.3 Libraries | 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: -------------------------------------+------------------------------------- There are a variety of issues caused by the impedance mismatch between GHC's use of Posix I/O interfaces on Windows (particularly with respect to console I/O), * #10542: Incorrect Unicode input on Windows Console * #7593: Unable to print exceptions of unicode identifiers * #4471: Incorrect Unicode output on Windows Console * #2189: hSetBuffering stdin NoBuffering doesn't work on Windows As pointed on in ticket:2189#comment:12 the ultimate solution to this would be to move all of GHC's IO to use the respective Win32 interfaces. = Also relevant = * #7353: Windows lacks support in the I/O manager * #806: hGetBufNonBlocking doesn't work on Windows * #3081: Double output after Ctrl+C on Windows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #4942: GHC.ConsoleHandler does not call back application when Close button is pressed
by GHC 20 Aug '18

20 Aug '18

#4942: GHC.ConsoleHandler does not call back application when Close button is pressed -------------------------------------+------------------------------------- Reporter: Amatic | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHC API | 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: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #11394 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4942#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14530: hWaitForInput causes the program to abort on Windows
by GHC 20 Aug '18

20 Aug '18

#14530: hWaitForInput causes the program to abort on Windows --------------------------------------+---------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- When running the following program on Windows (10): {{{#!hs readWithinNSecs :: IO () readWithinNSecs = withSocketsDo $ do h <- connectTo "localhost" (PortNumber 9090) hSetBuffering h NoBuffering readerTid <- forkIO $ politeReader h threadDelay (2 * 10^6) killThread readerTid where politeReader h = do info <- hShow h putStrLn info line <- ifM (hWaitForInput h (10^6)) (hGetLine h) (return "Nothing!") putStrLn $ "Got " ++ line }}} The program aborts with the following error: {{{#!text {loc=<socket: 380>,type=duplex (read-write),buffering=none} fdReady: fd is too big This application has requested the Runtime to terminate it in an unusual way. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12873: hWaitForInput with socket as handle excepts on windows
by GHC 20 Aug '18

20 Aug '18

#12873: hWaitForInput with socket as handle excepts on windows --------------------------------------+---------------------------------- Reporter: bwurk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- If I create a socket wrapped in a Handle (either by directly creating a handle with connectTo, or by creating a socket and wrapping it), hWaitForInput and hReady always give an exception with that handle. It excepts directly when calling, it does not wait until the given timeout of hWaitForInput has expired. The following code exposes the bug (requiring that a server-socket is listening on port 7892): {{{#!hs module SockDebug where import System.IO import Network main = do sock <- connectTo "localhost" (Service $ show 7892) hWaitForInput sock 5000 }}} Excepts with "hWaitForInput: invalid argument (Invalid argument)" Happens both on windows 10 and windows 7. This is the same error as in ticket 1198 so I'd guess that the bug is in cbits/inputReady.c as well, but I'm not an expert. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4