- ghc-tickets - Haskell.org

[GHC] #16229: Dump-parsed-ast fails for very large Fractional number constants
by GHC 24 Jan '19

24 Jan '19

#16229: Dump-parsed-ast fails for very large Fractional number constants -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The existing test file `T15271.hs` has {{{#!hs main = do print 1e646457008 print 1e646457009 -- T15271: This incorrectly printed 0.0 print 1e1555550000 -- This is still infinity print 1e1000000000 -- T15271: This incorrectly printed 0.0 }}} Trying to run `ghc --dump-parsed-ast` T15271.hs` fails, using up all available memory. When dumping the file in ghc-exacptrint, the start looks like this {{{ ({ tests/examples/ghc88-copied/T15271.hs:2:9-19 } Just (Ann (DP (0,1)) [] [] [((G AnnVal),DP (0,0))] Nothing Nothing) (HsOverLit (NoExt) (OverLit (NoExt) (HsFractional (FL (SourceText "1e646457008") (False) (:% (100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ..... }}} I am not sure if this is an actual problem, but it is worth noting. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation
by GHC 24 Jan '19

24 Jan '19

#15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import TestMod f :: Int f = $$(foo) main :: IO () main = main }}} {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeApplications #-} module TestMod where import Language.Haskell.TH.Syntax (Q, TExp) get :: forall a. Int get = 1 foo :: forall a. Q (TExp Int) foo = [|| get @a ||] }}} {{{ Test.hs:6:8: error: • The exact Name ‘a’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the result of the splice: $foo To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(foo) In the expression: $$(foo) | 6 | f = $$(foo) | ^^^ Test.hs:6:8: error: • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r3Kl :-> Identifier[f::Int, TopLevelLet [] True], r3PI :-> Identifier[main::IO (), TopLevelLet [r3PI :-> main] True]] • In the type ‘a’ In the expression: get @a In the result of the splice: $foo To see what the splice expanded to, use -ddump-splices | 6 | f = $$(foo) | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02`
by GHC 24 Jan '19

24 Jan '19

#13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- See the attached file. The compilation time grows exponentially with additional fields in `HuteStruct`. Tried with GHC-8.0.1 and quite recent HEAD (8.2) adding a field doubles the compilation time with `-O2`. - 9: 17s - 10: 34s - 11: 83s on my machine. With `-01` around 3sec, independently of the struct size. The original issue: https://github.com/yesodweb/yesod/issues/1348 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #16009: Deprecate `optional` from Text.ParserCombinators.ReadP
by GHC 24 Jan '19

24 Jan '19

#16009: Deprecate `optional` from Text.ParserCombinators.ReadP -------------------------------------+------------------------------------- Reporter: dbaynard | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | Keywords: Applicative, | Operating System: Unknown/Multiple Parsers, ReadP | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems there is some disagreement on what the type of `optional` should be, within `base`. `Control.Applicative` defines it as {{{#!haskell optional :: Alternative f => f a -> f (Maybe a) }}} By contrast, `Text.ParserCombinators.ReadP` defines it as {{{#!haskell optional :: ReadP a -> ReadP () }}} Worse, ReadP implements `Alternative`. So it entirely possible to specialise {{{#!haskell optional :: ReadP a -> ReadP (Maybe a). }}} In the broader Haskell ecosystem (and beyond) there is further confusion. The `Applicative` definition is used by `parsers`, `megaparsec` and purescript's `Data.Maybe`. The `ReadP` definition is used by `Parsec` and purescript's `Text.Parsing.StringParser`. `Cabal`, like `base` defines both. I propose to begin to deprecate `ReadP.optional` ASAP, following suggestions in https://www.reddit.com/r/haskell/comments/8cqgds/inconsistent_optional_defi…. Code which used the old form may still compile; otherwise `void` should be applied. There have been some suggestions for new names for the `ReadP` definition, such as `optionally` or `optional_`. It may be worth exporting this function directly from `Control.Applicative`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16226: printf g format specifier doesn't match the C standard behaviour
by GHC 23 Jan '19

23 Jan '19

#16226: printf g format specifier doesn't match the C standard behaviour -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ [nix-shell:/tmp]$ clang printg.c && ./a.out && cat printg.c 3122.55 #include <stdio.h> int main(void) { printf("%.16g\n", 3122.55); } [nix-shell:/tmp]$ runhaskell printg.hs && cat printg.hs 3122.5500000000000000 import Text.Printf (printf) main = printf "%.16g\n" (3122.55 :: Double) }}} Some more info here https://stackoverflow.com/questions/54162152/what- precisely-does-the-g-printf-specifier-mean Notably I'd expect GHC to give me the same answer as the shown C program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12920: Overzealous unused-top-binds
by GHC 23 Jan '19

23 Jan '19

#12920: Overzealous unused-top-binds -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example produces three warnings: {{{ module Foo () where type A = Int type B = A foo :: IO () foo = print (bar 3 :: B) bar :: a -> a bar = id }}} `ghci Foo -Wall` produces {{{ GHCi, version 8.0.1.20161117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:5:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘B’ Foo.hs:8:1: warning: [-Wunused-top-binds] Defined but not used: ‘foo’ Foo.hs:11:1: warning: [-Wunused-top-binds] Defined but not used: ‘bar’ Ok, modules loaded: Foo. }}} The three errors reported are inconsistent because GHC reports that `B` is unused, but somehow feels that `A` *is* used. It seems to me that two possibilities could work: 1. GHC reports 1 error: GHC should only report that `foo` is unused, since `A` is used in `B`, `B` is used in `foo`, and `bar` is used in `foo`. This seems like the best approach to me. 2. GHC reports 4 errors: One might choose to apply the definition of "unused" transitively so that, since `foo` is unused, everything used in `foo` is considered unused (unless "used" elsewhere). In this case, `A` should also be reported as unused, but it currently isn't. This definition would be exceedingly useful for removing dead code, but it also produces very noisy output when there is a lot of dead code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16223: hWaitForInput is broken on Windows
by GHC 23 Jan '19

23 Jan '19

#16223: hWaitForInput is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- As noted in #16160: {{{ Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( hWaitForInput-accurate-socket.hs, hWaitForInput-accurate-socket.o ) hWaitForInput-accurate-socket.hs:8:1: error: Could not find module ‘System.Posix.IO’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. *** unexpected failure for hWaitForInput-accurate-socket(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15470: Record projections with ambiguous types
by GHC 23 Jan '19

23 Jan '19

#15470: Record projections with ambiguous types -------------------------------------+------------------------------------- Reporter: sweirich | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- The following code fails {{{ {-# LANGUAGE DataKinds, KindSignatures, PolyKinds, TypeFamilies, RankNTypes, AllowAmbiguousTypes #-} module TypeLambda where data Fun a b type family App (f :: Fun t k) (x :: t) :: k data MONAD m = MONAD { return :: forall a. a -> App m a , (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b } }}} with the error message {{{ TypeLambda.hs:12:5: error: • Couldn't match type ‘App m b0’ with ‘App m b’ Expected type: App m a -> (a -> App m b) -> App m b Actual type: App m a -> (a -> App m b0) -> App m b0 NB: ‘App’ is a non-injective type family The type variable ‘b0’ is ambiguous • In the expression: (>>=) In an equation for ‘TypeLambda.>>=’: (TypeLambda.>>=) MONAD {>>= = (>>=)} = (>>=) • Relevant bindings include (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b (bound at TypeLambda.hs:12:5) | 12 | , (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b | ^^^^^ Failed, no modules loaded. }}} However, with ScopedTypeVariables and TypeApplications, it is possible to define the projections: {{{ data MONAD2 m = MONAD2 (forall a. a -> App m a) (forall a b. App m a -> (a -> App m b) -> App m b) bind :: forall b a m. MONAD2 m -> App m a -> (a -> App m b) -> App m b bind (MONAD2 _ b) = b @a @b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15470> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15646: ghci takes super long time to find the type of large fractional number
by GHC 23 Jan '19

23 Jan '19

#15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: type | 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: -------------------------------------+------------------------------------- {{{ :t 1e123456789 }}} takes more than 3 seconds to get the type info. {{{ :t 1e1234111111111111111111111 }}} shows a warning/error, {{{ GNU MP: Cannot allocate memory (size=93978265) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86

[GHC] #16186: Segfault when embedding data via file-embed.
by GHC 23 Jan '19

23 Jan '19

#16186: Segfault when embedding data via file-embed. ----------------------------------------+--------------------------------- Reporter: syd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I made a minimal reproducible-ish example here: https://github.com/NorfairKing/nix-segfault-haskell and described it at length here: https://github.com/NixOS/nixpkgs/issues/52439#issuecomment-453872693 The problem seems to occur (randomly) when literal strings are embedded via TH. By the way: to embed about 10MiB of data, 12 cores are being used at 100% which seems mildly absurd. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16