August 2017 - ghc-tickets

[GHC] #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't
by GHC 02 Sep '17

02 Sep '17

#14167: GHC often depicts H98 datatypes as GADTs when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: GADTs, | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Spun off from Phab:D3880.) There are at least a couple of points in the GHC codebase where poor decisions are made regarding whether to depict a datatype using H98 syntax or GADT syntax. In particular: 1. When reifying a datatype in Template Haskell, some complicated heuristics are used to determine whether a datatype is reified with `(Rec)GadtC` or not (see `Note [Reifying GADT data constructors]` in `TcSplice` for the horrifying details). But these heuristics are far from perfect, as they will cause some vanilla datatypes to be reified as GADTs (e.g., `data T a = (a ~ Int) => MkT`). 2. When pretty-printing a datatype (for instance, via the `:info` command in GHCi), GHC also chooses to sometimes depict vanilla datatypes as GADTs. For instance: {{{ λ> :set -XExistentialQuantification λ> data Foo a = Show a => Foo λ> :i Foo type role Foo nominal data Foo a where Foo :: Show a => Foo a }}} `Foo` is depicted as a GADT, despite the fact that we didn't use GADT syntax. There might be other places in the code that exhibit these symptoms too—we should take a closer look. I use the phrase "poor decisions" above since GHC really does have the right info it needs to make the correct decisions. That info is in the form of the `isGadtSyntaxTyCon`, which conveniently recalls whether a datatype was declared with GADT syntax or not. With this, we should be able to eliminate the flawed heuristics that GHC is currently using and accurately depict datatypes the way users wrote them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides)
by GHC 02 Sep '17

02 Sep '17

#14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I'm trying to define my own fancy strict maybe types, and so i've written some pattern synonyms to wrap them up. imagine my surprise when i find i can write bang patterns on the *right* hand side, but not the left hand! {{{ data MyMaybe a = JustC a | NothingC pattern MyJust :: a -> MyMaybe a -- pattern MyJust !a = JustC a -- this fails pattern MyJust a = JustC !a -- this is fine }}} is this deliberate or a leakage of how desugaring works? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13885: Template Haskell doesn't freshen GADT kind variables properly when imported from another package
by GHC 02 Sep '17

02 Sep '17

#13885: Template Haskell doesn't freshen GADT kind variables properly when imported from another package -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A simple way to illustrate this bug is with this code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} module Foo where import qualified Data.Type.Equality as DTE ((:~:)) import Language.Haskell.TH data a :~: b where Refl :: a :~: a $(return []) main :: IO () main = do putStrLn "Imported\n-----" putStrLn $(reify ''(DTE.:~:) >>= stringE . pprint) putStrLn "-----\n\nLocally defined\n-----" putStrLn $(reify ''(:~:) >>= stringE . pprint) putStrLn "-----" }}} Here, I'm pretty-printing the reified Template Haskell information about two datatypes: one that is imported from another package (`base`), and another that is defined locally. Aside from their definition sites, they are otherwise identical. However, when reifying them with Template Haskell, there is another distinction one can observe: {{{ $ /opt/ghc/8.2.1/bin/runghc Foo.hs Imported ----- data Data.Type.Equality.:~: (a_0 :: k_1) (b_2 :: k_1) where Data.Type.Equality.Refl :: forall (k_1 :: *) (a_0 :: k_1) . Data.Type.Equality.:~: a_0 a_0 ----- Locally defined ----- data Foo.:~: (a_0 :: k_1) (b_2 :: k_1) where Foo.Refl :: forall (k_3 :: *) (a_4 :: k_3) . Foo.:~: a_4 a_4 ----- }}} The locally defined information looks fine, but the one imported from `base` is suspicious. Namely, the `k_1` variable is used both in the datatype head and in the quantified variables for the constructor! To confirm this, you can print out more verbose info with `show` instead of `pprint`: {{{ Imported ----- TyConI (DataD [] Data.Type.Equality.:~: [KindedTV a_6989586621679026781 (VarT k_6989586621679026780),KindedTV b_6989586621679026782 (VarT k_6989586621679026780)] Nothing [ForallC [KindedTV k_6989586621679026780 StarT,KindedTV a_6989586621679026781 (VarT k_6989586621679026780)] [] (GadtC [Data.Type.Equality.Refl] [] (AppT (AppT (ConT Data.Type.Equality.:~:) (VarT a_6989586621679026781)) (VarT a_6989586621679026781)))] []) ----- Locally defined ----- TyConI (DataD [] Foo.:~: [KindedTV a_6989586621679016094 (VarT k_6989586621679016098),KindedTV b_6989586621679016095 (VarT k_6989586621679016098)] Nothing [ForallC [KindedTV k_6989586621679016108 StarT,KindedTV a_6989586621679016096 (VarT k_6989586621679016108)] [] (GadtC [Foo.Refl] [] (AppT (AppT (ConT Foo.:~:) (VarT a_6989586621679016096)) (VarT a_6989586621679016096)))] []) ----- }}} Sure enough, the variable `k_6989586621679026780` is used in both places. I would expect this not to happen, since the two sets of variables are scoped differently, and in practice, I have to work around this by freshening the type variables for the constructor, which is annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted"
by GHC 01 Sep '17

01 Sep '17

#14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Given the following code (full Stack project attached): {{{#!haskell module Foo where import Data.List data MyRecord = MyRecord { f1 :: Maybe String , f2 :: Maybe String , f3 :: Maybe String , f4 :: Maybe String , f5 :: Maybe String , f6 :: Maybe String , f7 :: Maybe String , f8 :: Maybe String , f9 :: Maybe String , f10 :: Maybe String , f11 :: Maybe String , f12 :: Maybe String } getComparisonValue x = ( f1 x , f2 x , f3 x , f4 x , f5 x , f6 x , f7 x , f8 x , f9 x ) doSort = sortOn getComparisonValue }}} The following error results: {{{ $ stack build ghc-bug-0.0.0: build (lib) Preprocessing library ghc-bug-0.0.0... [1 of 1] Compiling Foo ( Foo.hs, .stack-work/dist/x86_64 -linux-nopie/Cabal-1.24.2.0/build/Foo.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_s72t To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 324566 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package ghc-bug-0.0.0 using: /home/kostmo/.stack/setup-exe-cache/x86_64-linux-nopie/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64 -linux-nopie/Cabal-1.24.2.0 build lib:ghc-bug --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} Generating a tuple from elements of an object for the purpose of sorting is an idiom I have used in Python at times. The original use case in Haskell for me was excluding some fields of the record in the comparison (e.g. `f10`, `f11`, `f12` fields), rather than using a simple `sort` with `deriving Ord` on `MyRecord`. I worked around the issue for now by blanking out the record fields I with to ignore, instead of re-instantiating a tuple of field values: {{{#!haskell getComparisonValue x = x { f10 = Nothing , f11 = Nothing , f12 = Nothing } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14173: GHC hangs during type-checking
by GHC 31 Aug '17

31 Aug '17

#14173: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.2 doesn't terminate when type checking this file: {{{#!hs import Control.Lens import Data.Functor.Compose traverseCompose :: (a -> f b) -> g a -> f (h _) traverseCompose = _Wrapping Compose . traverse }}} This is the smallest type signature I could find that still causes the problem. GHCi infers the type without issue, and when I annotate it with the correct type signature, the file is successfully compiled. Using base-4.9.1.0, lens-4.15.1, and transformers-0.5.2.0 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14159: Decomposition of path sometimes fails
by GHC 31 Aug '17

31 Aug '17

#14159: Decomposition of path sometimes fails ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The path decomposition sometimes fails in SysTools with an `INVALID_FUNCTION` error. The fall back method never executes because of the unexpected raised exception. This makes the Windows tarballs a but unpredictable when placed in random folders and starting up from random cwd. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14159> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14161: Performance Problems on AST Dump
by GHC 31 Aug '17

31 Aug '17

#14161: Performance Problems on AST Dump -------------------------------------+------------------------------------- Reporter: h4ck3rm1k3 | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using the latest self compiler ghc ghc -O -ddump-to-file -ddump-parsed-ast with the file https://raw.githubusercontent.com/h4ck3rm1k3/gcc- ontology/master/tests/example_python_ast_in_haskell.hs After 2 hours I stopped it : PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20 0 1.000t 0.014t 0 D 3.3 94.0 108:29.80 ghc -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo
by GHC 31 Aug '17

31 Aug '17

#14034: GHC crash instead of compile error on GHC 8.2 with ApplicativeDo -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm filing this a sa proxy for user `sam2_` from IRC: {{{ $ cat Bug.hs {-# LANGUAGE ApplicativeDo #-} module Bug where doc = do () <- a () <- b c' <- c return d }}} {{{ $ ghc-8.2.1 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: out of memory (requested 1048576 bytes) }}} {{{ $ ghc-8.0.2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:9: error: Variable not in scope: a :: f () Bug.hs:6:9: error: Variable not in scope: b :: f () Bug.hs:7:9: error: Variable not in scope: c :: f a0 Bug.hs:8:10: error: Variable not in scope: d }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar
by GHC 31 Aug '17

31 Aug '17

#3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar -------------------------------------+------------------------------------- Reporter: ChrisKuklewicz | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): QSem and QSemN aren't deprecated, they were subsequently rewritten (after this thread) to be exception-safe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3160#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar
by GHC 30 Aug '17

30 Aug '17

#3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar -------------------------------------+------------------------------------- Reporter: ChrisKuklewicz | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): From this thread, I just found out that `QSem` defined in base in deprecated. It would be nice if this were mentioned in the haddock for `QSem`: http://hackage.haskell.org/package/base-4.10.0.0/docs/Control- Concurrent-QSem.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3160#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0