March 2018 - ghc-tickets

[GHC] #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics
by GHC 02 Mar '18

02 Mar '18

#14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 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: -------------------------------------+------------------------------------- See https://mail.haskell.org/pipermail/libraries/2018-February/028562.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy
by GHC 02 Mar '18

02 Mar '18

#11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE PolyKinds, TypeOperators, DataKinds, TypeFamilies, GADTs #-} module Bug where data family Sing (a :: k) data Schema = Sch [Bool] data instance Sing (x :: Schema) where SSch :: Sing x -> Sing ('Sch x) data instance Sing (x :: [k]) where SNil :: Sing '[] SCons :: Sing a -> Sing b -> Sing (a ': b) data G a where GCons :: G ('Sch (a ': b)) eval :: G s -> Sing s -> () eval GCons s = case s of -- SSch SNil -> undefined SSch (SCons _ _) -> undefined }}} Upon seeing this, GHC says {{{ Bug.hs:21:9: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: (SSch SNil) }}} So I uncomment the second-to-last line, inducing GHC to say {{{ Bug.hs:22:16: error: • Couldn't match type ‘a : b’ with ‘'[]’ Inaccessible code in a pattern with constructor: SNil :: forall k. Sing '[], in a case alternative • In the pattern: SNil In the pattern: SSch SNil In a case alternative: SSch SNil -> undefined }}} Thankfully, this pattern is much rarer than it once was, but it's a bit sad that it's still possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14098: Incorrect pattern match warning on nested GADTs
by GHC 02 Mar '18

02 Mar '18

#14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language GADTs #-} data App f a where App :: f a -> App f (Maybe a) data Ty a where TBool :: Ty Bool TInt :: Ty Int data T f a where C :: T Ty (Maybe Bool) -- Warning f :: T f a -> App f a -> () f C (App TBool) = () -- No warning g :: T f a -> App f a -> () g C (App x) = case x of TBool -> () }}} When compiling, with `-Wincomplete-patterns`: {{{ Foo.hs:15:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: C (App TInt) | 15 | f C (App TBool) = () | ^^^^^^^^^^^^^^^^^^^^ }}} I'm sorry for such a complicated example, but I wasn't able to reduce it any further than this. The gist of the problem is that this code gives a pattern matching non- exhaustiveness warning when matching a nested pattern, when pulling out a value then matching on it produces no warning (correctly). It also seems to have to do with using a type constructor (`Maybe`) within the constructor definition of `App`, as changing it to {{{#!hs data App f a where App :: f a -> App f a ... data T f a where C :: T Ty Bool }}} does not give a warning, even when `App` is modified further to force it to be a proper GADT. This might be a known limitation of the checker, but given that it works fine when the nesting is removed, I would think it would be more of a bug. Thanks to Iavor for helping me minimize the test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14544: doCorePass has at least one missing case
by GHC 02 Mar '18

02 Mar '18

#14544: doCorePass has at least one missing case -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: newcomer | 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 is a catch all at the end of `doCorePass` which hides the fact that `doCorePass` should be total. In particular `doCorePass` is not implemented for `CoreOccurAnal` and so either `CoreOccurAnal` should be removed from `CoreToDo` or implemented properly in `doCorePass`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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

Re: [GHC] #5: fails if library has main()
by GHC 02 Mar '18

02 Mar '18

#5: fails if library has main() --------------------------------+---------------------- Reporter: cwitty | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 5.02 Resolution: Wont Fix | Keywords: Type of failure: None/Unknown | --------------------------------+---------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"5f6fcf7808b16d066ad0fb2068225b3f2e8363f7/ghc" 5f6fcf78/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f6fcf7808b16d066ad0fb2068225b3f2e8363f7" Compile with `--via-asm` when cross compiling. This bumps `hsc2hs` and adds the new `--via-asm` flag, which allows to successfully cross compile the win32 lirbary. - Compile with `--via-asm` when cross compiling. This requires haskell/hsc2hs#5 (https://github.com/haskell/hsc2hs/pull/5) Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4439 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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