February 2019 - ghc-tickets

[GHC] #16327: NCG: Don't double adjust SP before calls on Windows.
by GHC 15 Feb '19

15 Feb '19

#16327: NCG: Don't double adjust SP before calls on Windows. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Windows ABI requires callers to allocate 32 byte of space in the parameter stack space. This should be rolled into the stack adjustment for Currently we generate this code: {{{ subq $8,%rsp # for stack alignment? movq %r13,%rcx # Arg1 movq %rbx,%rdx # Arg2 subq $32,%rsp # Reserve "shadow" space + align stack if required xorl %eax,%eax # Not required for windows, even on linux only for vararg functions call newCAF addq $40,%rsp testq %rax,%rax je _c9N5 }}} Ideally this should become {{{ movq %r13,%rcx # Arg1 movq %rbx,%rdx # Arg2 subq $40,%rsp # Reserve "shadow" space xorl %eax,%eax call newCAF addq $40,%rsp testq %rax,%rax je _c9N5 }}} I haven't looked deeper into this and don't plan in the near future. But if anyone is interested I'm willing to lend a hand. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16322: "deriving newtype instance" generates an infinite loop
by GHC 15 Feb '19

15 Feb '19

#16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | 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: -------------------------------------+------------------------------------- I was trying to create a newtype instance for the `SqlSelect`(https://hackage.haskell.org/package/esqueleto-2.5.3/docs /Database-Esqueleto-Internal-Sql.html#t:SqlSelect) class from the `esqueleto` library. It has multiple type arguments so I was using StandaloneDeriving: {{{ newtype X a b = X { unX :: b } deriving newtype instance SqlSelect b c => SqlSelect (X a b) (X a c) }}} Unfortunately, this generates code which must include an infinite loop, because the compiled code spins, but replacing it with the obvious handwritten instance seems to fix the problem. Apologies if this has been reported or fixed elsewhere, I was unable to find any matching issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16306: Hadrian: First test after a full rebuild normally fails due to an additional stdout line
by GHC 15 Feb '19

15 Feb '19

#16306: Hadrian: First test after a full rebuild normally fails due to an additional stdout line -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After pulling down the lates updates to my local GHC tree, I normally do the following: {{{ hadrian/build.sh clean hadrian/build.sh --flavour=devel2 -j4 hadrian/build.sh test --flavour=devel2 --freeze1 --only=T99999 }}} The first test fails with: `Actual stdout output differs from expected:` stdout contains an additonal line, obviously generated by Hadrian: {{{ +Linking /home/roland/Projekte/ghc/testsuite/mk/ghc-config ... }}} When I rerun the test, Hadrian does not re-link `ghc-config` and everything works fine! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16313: Core Lint warning (Unsafe coercion: {left, right}-hand type is levity-polymorphic)
by GHC 15 Feb '19

15 Feb '19

#16313: Core Lint warning (Unsafe coercion: {left,right}-hand type is levity- polymorphic) -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: -------------------------------------+------------------------------------- goldfire claims [https://github.com/goldfirere/singletons/issues/383 this] is a GHC bug, so I'm reporting it here: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind (Type) import GHC.Exts (TYPE) import Type.Reflection (TypeRep, (:~~:)(..), eqTypeRep) import Unsafe.Coerce (unsafeCoerce) data SBool :: Bool -> Type where SFalse :: SBool False STrue :: SBool True type family DefaultEq (a :: k) (b :: k) :: Bool where DefaultEq a a = 'True DefaultEq a b = 'False sEqTypeRep :: forall rep (x :: TYPE rep) (y :: TYPE rep). TypeRep x -> TypeRep y -> SBool (DefaultEq x y) sEqTypeRep tra trb = case eqTypeRep tra trb of Just HRefl -> STrue Nothing -> unsafeCoerce SFalse }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs -O -dcore-lint -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint warnings : in result of Simplifier *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Float inwards *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Called arity analysis *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Demand analysis *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Worker Wrapper binds *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Exitification transformation *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Common sub-expression *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Float inwards *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Demand analysis *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Tidy Core *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of CorePrep *** <no location info>: warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg <no location info>: warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16319: unexpected difference between newtype and data
by GHC 15 Feb '19

15 Feb '19

#16319: unexpected difference between newtype and data ----------------------------------------+--------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 following code compiles fine {{{#!hs -- | A referable class -- An object can only have one reference. -- For example, a function is either referenced by name of by signature but not both. class ( Eq (Ref a) , Ord (Ref a) , Hashable (Ref a) , Show (Ref a) , Read (Ref a) , Data (Ref a) ) => Referable a where type Ref a toRef :: a -> Ref a data Referable a => RefMap a = RefMap { -- | the HashMap toHashMap :: HashMap.Map (Ref a) a } deriving (Eq, Ord, Show, Read, Data) }}} yet following the hlint hint to replace data by the equivalent newtype results in the following issues: {{{ src\TorXakis\Referable.hs:59:43: error: * Could not deduce (Eq (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: Eq a bound by the deriving clause for `Eq (RefMap a)' at src\TorXakis\Referable.hs:59:43-44 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Eq (RefMap a)) | 59 | } deriving (Eq, Ord, Show, Read, Data) | ^^ src\TorXakis\Referable.hs:59:47: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: Ord a bound by the deriving clause for `Ord (RefMap a)' at src\TorXakis\Referable.hs:59:47-49 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Ord (RefMap a)) | 59 | } deriving (Eq, Ord, Show, Read, Data) }}} I assume this is a bug... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16323: Cannot deduce X error with X provided
by GHC 15 Feb '19

15 Feb '19

#16323: Cannot deduce X error with X provided ----------------------------------------+--------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 following code {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} module TorXakis.Test ( -- * Referable Referable(..) ) where import Data.Hashable import qualified Data.HashMap as HashMap -- | A referable class class Referable a where type Ref a toRef :: a -> Ref a -- | Map of Referable objects. data (Referable a, Ord (Ref a), Hashable (Ref a)) => RefMap a = RefMap { -- | the HashMap toHashMap :: HashMap.Map (Ref a) a } deriving (Eq, Ord, Show, Read) }}} gives the following errors {{{ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:43: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Eq a, Referable a) bound by the deriving clause for `Eq (RefMap a)' at src\TorXakis\Test.hs:20:43-44 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Eq (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:47: error: * Could not deduce (Hashable (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Ord a, Referable a) bound by the deriving clause for `Ord (RefMap a)' at src\TorXakis\Test.hs:20:47-49 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Ord (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:52: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Show a, Referable a) bound by the deriving clause for `Show (RefMap a)' at src\TorXakis\Test.hs:20:52-55 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Show (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:58: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Read a, Referable a) bound by the deriving clause for `Read (RefMap a)' at src\TorXakis\Test.hs:20:58-61 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Read (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^^ -- While building package txs-basics-0.1.0.0 using: C:\sr\setup-exe-cache\x86_64-windows-integersimple\Cabal- simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.stack-w ork\dist\67675594 build lib:txs-basics --ghc-options " -ddump-hi -ddump- to-file" Process exited with code: ExitFailure 1 }}} yet the requirements such as {{{Ord (Ref a)}}} are clearly given to the data definition! possibly related to #16319 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations
by GHC 15 Feb '19

15 Feb '19

#16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | 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: -------------------------------------+------------------------------------- Phab:D5180 introduced a slight regression to the error messages. In this code {{{#!hs data T = forall a. MkT a }}} GHC used to complain {{{ rnfail053.hs:5:10: Not a data constructor: ‘forall’ Perhaps you intended to use ExistentialQuantification }}} but then the message has become {{{ rnfail053.hs:5:18: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16176: Let-insertion for template haskell
by GHC 15 Feb '19

15 Feb '19

#16176: Let-insertion for template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple TypedTemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using Template Haskell to generate programs it's very easy to end up with a lot of duplication as splices are naively spliced in place. For example {{{ foo x = [|| $$x + $$x ||] }}} Will generate a program which completely duplicates its argument. In this case I can manually remove the duplicate by inserting a let. {{{ foo x = [|| let x' = $$x in x' + x' ||] }}} Not too bad but a bit annoying to have to do manually. When constructing bigger programs however this process becomes tedious or impossible to do correctly by hand. {{{ foo :: (Q (TExp (Bool)) -> Q (TExp Int)) -> Q (TExp Int) foo xf = [|| (let x = True in $$(xf [|| x ||])) + (let x = False in $$(xf [|| x ||]) ||] }}} Now if I pass a constant function to `foo`, the resulting code won't mention `x` so it could be floated out. However, there's not way I can tell that without running `xf` so I can't perform the same transformation as I did for the earlier program and manually insert a let. In the case of splicing in fully static data you really want it to float to the top-level and turn into a CAF. The proposal of this ticket is to implement something like the mechanism for let-insertion in metaocaml. http://okmij.org/ftp/meta-programming/#let-insert We add two new primitives: {{{ genlet :: Q (TExp a) -> Q (TExp a) let_locus :: Q (TExp a) -> Q (TExp a) }}} `genlet` marks a code value that we want to float. `let_locus` marks places where we want to insert a let. When we evaluate the code fragment and encounter a `genlet` call, whatever the argument evaluates to is floated as far upwards as possible and inserted at the position of one of the loci. For example, {{{ sqr :: Code Int -> Code Int sqr c = [|| $$c + $$c ||] sqr_let :: Code Int -> Code Int sqr_let c = let_locus (sqr (genlet c)) }}} Splicing `sqr [|| 1 ||]` will result in `1 + 1` but `sqr_let [|| c ||]` will equal `let x = 1 in x + x ||]`. It's important to do this earlier rather than later as a lot of duplication can take place which the simplifier does not like. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16324: ghc-pkg: Batched package unregister takes time linear to the batch size
by GHC 15 Feb '19

15 Feb '19

#16324: ghc-pkg: Batched package unregister takes time linear to the batch size -------------------------------------+------------------------------------- Reporter: qrilka | 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: -------------------------------------+------------------------------------- When started using batched `ghc-pkg unregister` (implemented in #12637) we have noticed that it did not give much time speed improvements. I've created a simple reproduction of that behavior in https://github.com/qrilka/pkg-db-problems (which is a bit of package db abuse of cause as the same package gets registered multiple times with different ids). The last run of that script gave me: {{{ qrilka@qdesktop ~/ws/h/pkg-db-problems $ ./test.sh Up to date Reading package info from "dist- newstyle/packagedb/ghc-8.6.3/sample-1.0.0-inplace.conf" ... done. sample-1.0.0: Warning: haddock-interfaces: /home/qrilka/ws/h/pkg-db- problems/dist- newstyle/build/x86_64-linux/ghc-8.6.3/sample-1.0.0/doc/html/sample/sample.haddock doesn't exist or isn't a file sample-1.0.0: Warning: haddock-html: /home/qrilka/ws/h/pkg-db-problems /dist-newstyle/build/x86_64-linux/ghc-8.6.3/sample-1.0.0/doc/html/sample doesn't exist or isn't a directory Unregistering single package: real 0m0,196s user 0m0,175s sys 0m0,020s Unregistering 15 packages: real 0m2,471s user 0m2,340s sys 0m0,130s }}} Which clearly shows speed problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16321: Suggest -XScopedTypeVariables instead of -XRankNTypes
by GHC 14 Feb '19

14 Feb '19

#16321: Suggest -XScopedTypeVariables instead of -XRankNTypes -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | 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: -------------------------------------+------------------------------------- When the parser encounters an explicit `forall` when `-XExplicitForAll` is disabled, it tries to guess what the user meant and suggests to enable `-XRankNTypes`: {{{ Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> }}} Richard argues we are better off suggesting `-XScopedTypeVariables` by default: > Consider these workflows: > > 1a. User is writing a higher-rank type without extensions. GHC suggests to enable RankNTypes. Program is accepted. > > 1b. User is writing a higher-rank type without extensions. GHC suggests to enable ScopedTypeVariables. User compiles again, and GHC suggests to enable RankNTypes. Program is accepted. > > 2a. User is writing a program that requires scoped type variables. GHC suggests to enable RankNTypes. Program is rejected with inscrutable type errors claiming that `a` is not `a0`. > > 2b. User is writing a program that requires scoped type variables. GHC suggests to enable ScopedTypeVariables. Program is accepted. > > The question is: what's worse: 1b, or 2a? I claim that 2a is worse, and so I favor making the change so that we avoid 2a in favor of sometimes incurring 1b. The problem here is that in the grand scheme of things, we want neither 1b nor 2a to happen. What would it take to implement a proper diagnostic and always suggest the appropriate extension? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0