March 2017 - ghc-tickets

[GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows
by GHC 07 Mar '17

07 Mar '17

#13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Commit c8d995db5d743358b0583fe97f8113bf9047641e in ghc bumped the `time` submodule to the latest version 4eb06c0e (`time-1.8`). But it caused a Core Lint error while compiling `Distribution.Compat.Time`, in the Cabal library: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** <no location info>: warning: In the expression: $wsystemToUTCTime (case lvl_sdDL of v_B1 { I# v_B2 -> v_B2 }) (case lvl_sdDM of v_B1 { W# v_B2 -> v_B2 }) This argument does not satisfy the let/app invariant: case lvl_sdDL of v_B1 { I# v_B2 -> v_B2 } }}} See https://phabricator.haskell.org/harbormaster/build/21371/ for the full build log. For now the submodule bumps have been reverted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better
by GHC 07 Mar '17

07 Mar '17

#13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Like orphan rewrite rules, it's possible to define orphan `COMPLETE` sets. For instance: {{{#!hs module Foo where {-# COMPLETE False #-} }}} I suppose that we could define an orphan `COMPLETE` set as one that lives in a module where none of the conlikes are defined (or should we say "where one or more of the conlikes are not defined"? I'm not sure.) Like orphan `RULES`, orphan `COMPLETE` sets are important to track properly when transitively reading from interface files, as failing to bring an orphan `COMPLETE` set into scope could affect pattern-match exhaustivness warnings that users see. After discussing this with rwbarton and mpickering IRC, we decided that one of the two should happen: 1. Treat orphan `COMPLETE` sets like orphan `RULES`. That is, mark a module as an orphan if it defines an orphan `COMPLETE` set, and thread a "`COMPLETE` pragma visibility" state through various places. 2. Disallow orphan `COMPLETE` sets entirely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13350: COMPLETE sets aren't read from external packages
by GHC 06 Mar '17

06 Mar '17

#13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you define these two modules: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo where data KindRep = KindRepTyConApp | KindRepVar | KindRepApp | KindRepFun | KindRepTYPE | KindRepTypeLitS | KindRepTypeLitD pattern KindRepTypeLit :: KindRep pattern KindRepTypeLit = KindRepTypeLitD {-# COMPLETE KindRepTyConApp, KindRepVar, KindRepApp, KindRepFun, KindRepTYPE, KindRepTypeLit #-} }}} {{{#!hs module Bar where import Foo krInt :: KindRep -> Int krInt KindRepTyConApp{} = 0 krInt KindRepVar{} = 1 krInt KindRepApp{} = 2 krInt KindRepFun{} = 3 krInt KindRepTYPE{} = 4 krInt KindRepTypeLit{} = 5 }}} And you compile `Bar.hs` with `-Wall` on, it will not emit any pattern- match exhaustiveness warnings, as expected. However, something different happens if you import all of these `KindRep` conlikes from `Type.Reflection.Unsafe` instead: {{{#!hs module Bar where import Type.Reflection.Unsafe krInt :: KindRep -> Int krInt KindRepTyConApp{} = 0 krInt KindRepVar{} = 1 krInt KindRepApp{} = 2 krInt KindRepFun{} = 3 krInt KindRepTYPE{} = 4 krInt KindRepTypeLit{} = 5 }}} {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -Wall Bar.hs GHCi, version 8.1.20170228: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bar ( Bar.hs, interpreted ) Bar.hs:6:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘krInt’: Patterns not matched: (KindRepTypeLitS _ _) (KindRepTypeLitD _ _) | 6 | krInt KindRepTyConApp{} = 0 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} When the `COMPLETE` set is defined in a module in an //external package// (`base:Type.Reflection.Unsafe`, in this example), GHC doesn't properly take it into account when emitting pattern-match exhaustiveness warnings! This makes `COMPLETE` sets not terribly useful in practice at the moment. (NB: `Type.Reflection.Unsafe`'s definitions of `KindRepTyConApp` //et al.// aren't quite the same as what I defined above, but their exact definitions aren't important here, just that they have the same names and `COMPLETE` set. And this is the only `COMPLETE` set that I could defined in the boot libraries at the moment, making it convenient to use.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13174: Fix mismatch between unsafeDupablePerformIO and note
by GHC 06 Mar '17

06 Mar '17

#13174: Fix mismatch between unsafeDupablePerformIO and note -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.1 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: -------------------------------------+------------------------------------- `ghc/libraries/base/GHC/IO/Unsafe.hs` contains the following note: {{{ -- Note [unsafeDupablePerformIO is NOINLINE] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Why do we NOINLINE unsafeDupablePerformIO? See the comment with -- GHC.ST.runST. Essentially the issue is that the IO computation -- inside unsafePerformIO must be atomic: it must either all run, or -- not at all. If we let the compiler see the application of the IO -- to realWorld#, it might float out part of the IO. }}} However, `unsafeDupablePerformIO` does not actually have a `NOINLINE` pragma. So either the note is out of date and should be removed/modified, or someone messed up the code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11076: Demand information of foreign calls is wrong
by GHC 06 Mar '17

06 Mar '17

#11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Foreign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also causes some trouble for GHCJS. I hope to get a fix in 7.10.3. Can we leave the strictness sig out entirely perhaps? Most arguments would be trivially strict since they're unboxed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11076> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13141: Don't check for Perl in ./configure when not splitting objects
by GHC 06 Mar '17

06 Mar '17

#13141: Don't check for Perl in ./configure when not splitting objects -------------------------------------+------------------------------------- Reporter: dobenour | Owner: dobenour Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- GHC needs Perl for exactly two reasons: - To run `boot` and the Autotools - For the splitter As such, there is no reason to check for Perl in `./configure` unless split-objs is supported. Even then, Perl is optional. The current check most likely comes from the days of the Evil Mangler. I'll take this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD
by GHC 06 Mar '17

06 Mar '17

#13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Git HEAD of containers compiles fine with ghc-8.0.1, but when compiling with GHC git HEAD gives core lint errors: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** <no location info>: warning: In the expression: tagToEnum# @ Bool (reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi) This argument does not satisfy the let/app invariant: reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi *** Offending Program *** Rec { $dTypeable_s9vn :: Proxy# Set -> TypeRep }}} This issue can be reproduced using: {{{ (cd libraries/containers ; git checkout master ; git pull) perl boot && ./configure && make clean && make -j }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #13369: Float-out is not idempotent
by GHC 06 Mar '17

06 Mar '17

#13369: Float-out is not idempotent -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- Consider {{{ f x = BIG }}} where BIG is bottoming. In HEAD, the float-out pass decides to float BIG to the top level, producing {{{ lvl x = BIG f x = lvl x }}} which is obviously stupid. There's a whole Note to explain this problem and how we avoid it: {{{ Note [Floating from a RHS] ~~~~~~~~~~~~~~~~~~~~~~~~~~ When float the RHS of a let-binding, we don't always want to apply lvlMFE to the body of a lambda, as we usually do, because the entire binding body is already going to the right place (dest_lvl). A particular example is the top level. Consider concat = /\ a -> foldr ..a.. (++) [] We don't want to float the body of the lambda to get lvl = /\ a -> foldr ..a.. (++) [] concat = /\ a -> lvl a That would be stupid. }}} But I forgot to take account of the possibility that `abs_vars` might abstract over Ids. Easily fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13383: ghc: panic!
by GHC 06 Mar '17

06 Mar '17

#13383: ghc: panic! -------------------------------------+------------------------------------- Reporter: henenenerik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Panic | Operating System: Windows Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tried to compile some code provided in the course I'm taking and caused ghc to panic. Got this in my command prompt: {{{ [1 of 1] Compiling Main ( temp.hs, temp.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] throw_a2dw :: t_a2dv[tau:1] (CHoleCan: throw) [W] throw_a2eY :: t_a2eX[tau:1] (CHoleCan: throw) [W] throw_a2fc :: t_a2fb[tau:1] (CHoleCan: throw)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] Trac email verification for user: henenenerik
by GHC 06 Mar '17

06 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=3-SC1QCT> Username: henenenerik Verification Token: 3-SC1QCT -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0