February 2018 - ghc-tickets

[GHC] #14843: Can't splice a partially applied PromoteTupleT type from Template Haskell
by GHC 02 Mar '18

02 Mar '18

#14843: Can't splice a partially applied PromoteTupleT type from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH.Syntax type T1 = $(return (PromotedTupleT 2)) type T2 = $([t| '(,) |]) type T3 = $(return (PromotedT (tupleDataName 2))) }}} The splices for `T2` and `T3` both work. However, the splice for `T1` causes Template Haskell to have a conniption: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:13: error: • Malformed type PromotedTupleT 2 When splicing a TH type: '(,) • In the untyped splice: $(return (PromotedTupleT 2)) | 7 | type T1 = $(return (PromotedTupleT 2)) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12706: Collecting type info is slow
by GHC 02 Mar '18

02 Mar '18

#12706: Collecting type info is slow -------------------------------------+------------------------------------- Reporter: vshabanov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- With `:set +c` option in GHCi, I'm waiting for 10-15 seconds for {{{ Collecting type info for 34 module(s) ... }}} after both first load and subsequent reloads, even if only top-level module was modified. And GHCi uses about 1.5-2x more memory than it uses without `:set +c`. My app has about 30k lines of code. Is it expected behavior and some performance improvements are planned or it's a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later
by GHC 02 Mar '18

02 Mar '18

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 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: -------------------------------------+------------------------------------- As observed [https://github.com/ekmett/lens/issues/781#issuecomment-357841481 here], any attempt to run [https://hackage.haskell.org/package/doctest-0.13.0 doctest] on a module that contains an `ANN` will result in a segfault—but only under certain settings! To explain better what I mean, let's look at a stripped-down version of `doctest`: {{{#!hs -- Bug.hs module Main (main) where import Control.Applicative ((<|>)) import Control.Monad.IO.Class (liftIO) import Data.Char (isSpace) import Data.List (dropWhileEnd) import Digraph (flattenSCCs) import GHC (depanal, getSessionDynFlags, guessTarget, loadModule, noLoc, parseDynamicFlags, parseModule, runGhc, setSessionDynFlags, setTargets, topSortModuleGraph, typecheckModule) import System.Directory (findExecutable) import System.Process (readProcess) getLibDir :: IO FilePath getLibDir = do Just ghcPath <- findExecutable "ghc" <|> findExecutable "ghc-stage2" dropWhileEnd isSpace <$> readProcess ghcPath ["--print-libdir"] "" main :: IO () main = do libdir <- getLibDir putStrLn libdir runGhc (Just libdir) $ do (dynflags, _, _) <- getSessionDynFlags >>= flip parseDynamicFlags (map noLoc ["-package base"]) _ <- setSessionDynFlags dynflags mapM (`guessTarget` Nothing) ["Foo.hs"] >>= setTargets mods <- depanal [] False let sortedMods = flattenSCCs (topSortModuleGraph False mods Nothing) let f theMod = do liftIO $ putStrLn "Before parseModule" m1 <- parseModule theMod liftIO $ putStrLn "Before typecheckModule" m2 <- typecheckModule m1 liftIO $ putStrLn "Before loadModule" m3 <- loadModule m2 liftIO $ putStrLn "After loadModule" return m3 mods' <- mapM f sortedMods mods' `seq` return () }}} As well as a module with an `ANN`: {{{#!hs module Foo where {-# ANN module "I'm an annotation" #-} }}} If you attempt to compile and run `Bug.hs` with GHC 8.2.2, everything is fine and dandy: {{{ $ PATH=/opt/ghc/8.2.2/bin:$PATH ghc -fforce-recomp Bug.hs -package ghc [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ PATH=/opt/ghc/8.2.2/bin:$PATH ./Bug /opt/ghc/8.2.2/lib/ghc-8.2.2 Before parseModule Before typecheckModule Before loadModule After loadModule }}} But if these two criteria are met: * You're using GHC 8.4.1-alpha * You're using Ubuntu 16.04 or later Then this will result in a segfault! {{{ $ PATH=/opt/ghc/8.4.1/bin:$PATH ghc -fforce-recomp Bug.hs -package ghc [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ PATH=/opt/ghc/8.4.1/bin:$PATH ./Bug /opt/ghc/8.4.1/lib/ghc-8.4.0.20171222 Before parseModule Before typecheckModule Segmentation fault (core dumped) $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 17.04 Release: 17.04 Codename: zesty }}} The second criteria about Ubuntu version is the most baffling part, but the segfault does not appear to occur when I try it on, for instance, an Ubuntu 14.04 machine: {{{ $ PATH=/opt/ghc/8.4.1/bin:$PATH ghc -fforce-recomp Bug.hs -package ghc [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ PATH=/opt/ghc/8.4.1/bin:$PATH ./Bug /opt/ghc/8.4.1/lib/ghc-8.4.0.20171222 Before parseModule Before typecheckModule Before loadModule After loadModule $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall
by GHC 02 Mar '18

02 Mar '18

#14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The following partial function will pass {{{-Wall}}} {{{#!haskell -- program 1 {-# LANGUAGE MultiWayIf #-} foo :: Bool -> Int foo b = if | b -> 23 }}} While the following two alternatives will not: {{{#!haskell -- program 2 foo :: Bool -> Int foo b | b = 23 }}} {{{#!haskell -- program 3 foo :: Bool -> Int foo b = case () of () | b -> 23 }}} Note that the GHC User's Guide states that "program 1" and "program 3" are equivalent. 1. Is this a bug or by design? 2. I guess at the very least we would want to update the User's Guide -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins
by GHC 02 Mar '18

02 Mar '18

#12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- When building lambdabot-haskell-plugins, Lambdabot.Plugin.Haskell.Pl.Parser compiles without incident on the non- profiling run, but cripples the build machine on the profiling run. An excerpt of -v3 output is below to show the number of terms skyrocketing. *** Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Common sub-expression = {terms: 39,049, types: 30,851, coercions: 990} !!! Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 72.00 milliseconds, allocated 44.536 megabytes *** Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Float inwards = {terms: 39,049, types: 30,851, coercions: 990} !!! Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 68.00 milliseconds, allocated 60.337 megabytes *** Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Simplifier iteration=1 = {terms: 977,045, types: 299,334, coercions: 1,058} Result size of Simplifier iteration=2 = {terms: 926,036, types: 263,306, coercions: 932} Result size of Simplifier = {terms: 922,724, types: 262,202, coercions: 932} !!! Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 15480.00 milliseconds, allocated 9384.823 megabytes *** CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Tidy Core = {terms: 922,623, types: 261,789, coercions: 865} !!! CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 2060.00 milliseconds, allocated 613.585 megabytes writeBinIface: 95 Names writeBinIface: 259 dict entries *** CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of CorePrep = {terms: 1,128,145, types: 347,063, coercions: 865} !!! CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 3468.00 milliseconds, allocated 1718.453 megabytes *** Stg2Stg: *** CodeGen [Lambdabot.Plugin.Haskell.Pl.Parser]: -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #14817: GHC 8.4.1 pretty-prints data family instances with redundant kind signatures using -ddump-splices
by GHC 02 Mar '18

02 Mar '18

#14817: GHC 8.4.1 pretty-prints data family instances with redundant kind signatures using -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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: -------------------------------------+------------------------------------- Consider this program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| data family Foo :: * data instance Foo :: * |]) }}} On GHC 8.2.2, this gives the following `-ddump-splices` output: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(7,31): Splicing declarations [d| data family Foo_a1sB :: * data instance :: * |] ======> data family Foo_a494 :: GHC.Types.Type data instance :: GHC.Types.Type }}} But on GHC 8.4.1, we have: {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(7,31): Splicing declarations [d| data family Foo_a1xd :: * data instance Foo_a1xd :: * :: * |] ======> data family Foo_a487 :: GHC.Types.Type data instance Foo_a487 :: GHC.Types.Type :: GHC.Types.Type }}} Notice how there is a redundant kind signature in `data instance Foo_a1xd :: * :: *`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling
by GHC 02 Mar '18

02 Mar '18

#14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling -------------------------------------+------------------------------------- Reporter: clinton | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The GHC docs for GeneralisedNewtypeDeriving at (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #generalised-derived-instances-for-newtypes) suggest British spelling should be accepted, and indeed it's the preferred spelling in the docs. However GHC 8.2 throws an error. I haven't tested this against HEAD so if it's fixed there please feel free to close. I know this is a bit picky but it's caught me out a few times and I couldn't see it previously reported (I may have missed it though). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14856: GHC API: Linker failure on loading target multiple times
by GHC 01 Mar '18

01 Mar '18

#14856: GHC API: Linker failure on loading target multiple times ----------------------------------------+--------------------------- Reporter: fizzixnerd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.2 Keywords: GHC API Linker | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------- Minimum Working Example: https://github.com/Fizzixnerd/ghc-bug `stack exec -- ghc --version` >The Glorious Glasgow Haskell Compilation System, version 8.2.2 `uname --all` >Linux <REDACTED> 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux Description: Loading a dynamic module more than once causes a linker failure with the following message: ''' /usr/bin/ld.gold: error: cannot find -lghc_2 collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** Exception: ExitFailure 1 ''' `-lghc_2' sometimes is `-lghc_5' or other numbers. Steps to Reproduce: 1) Clone above repo. 2) `stack build` 3) `stack exec mwe-exe` The repo code will use the GHC API to load a string from the file contained in scripts/ named `val'. There are three functions defined in src/Lib.hs. `anotherFunc' should behave normally. `someFunc' should display the bad behavior. Notes: - When using `intero`: intero must be restarted if this bug is encountered at the prompt, or else you will keep getting it over and over again. - I could not figure out how to load it up without using the `-dynamic' flag, but that should probably be checked out too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14856> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14867: make targets for documentation not working
by GHC 28 Feb '18

28 Feb '18

#14867: make targets for documentation not working -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- None of the documentation targets mentioned in the Wiki work: https://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets#Documentatio… As far as I can see there's no mention of how to build documentation in the entire wiki. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14870: Runtime performance regression in 8.4
by GHC 28 Feb '18

28 Feb '18

#14870: Runtime performance regression in 8.4 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- varosi [[https://mail.haskell.org/pipermail/glasgow-haskell- users/2018-February/026701.html|reports]] that the code for his project is slower in 8.4.1 than 8.2.2: > Yesterday I successfully compiled it with GHC 8.4.1-rc1. I got compiled it > with 8.2.2 and 8.0.2 as well and ran tests for about a minute each on my > Intel Core i7 machine on Windows 10 x64. > > I got this results: > > GHC 8.4.1-rc1 > Average time: 61.87s > > GHC 8.2.2 > Average time: 60.09s > > GHC 8.0.2 > Average time: 67.07s > We should look into why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1