- ghc-tickets - Haskell.org

[GHC] #16133: TH can sneak in TypeApplications without enabling the extension
by GHC 16 Jan '19

16 Jan '19

#16133: TH can sneak in TypeApplications without enabling the extension -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug1 where import Language.Haskell.TH $([d| f :: Int f = $(varE 'id `appTypeE` conT ''Int `appE` litE (integerL 42)) |]) }}} But it shouldn't: this splices in code that uses `TypeApplications`, but the language extension isn't enabled! What's worse, this is inconsistent with visible kind applications, since the following code //is// rejected: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug2 where import Data.Kind import Language.Haskell.TH hiding (Type) data P (a :: k) = MkP $([d| type P' = $(conT ''P `appKindT` conT ''Type) |]) }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug2.hs [1 of 1] Compiling Bug2 ( Bug2.hs, Bug2.o ) Bug2.hs:10:3: error: Illegal visible kind application ‘Type’ Perhaps you intended to use TypeApplications | 10 | $([d| type P' = $(conT ''P `appKindT` conT ''Type) |]) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Let's bring the two into harmony. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15779: Follow-ups to D5169
by GHC 16 Jan '19

16 Jan '19

#15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Simonmar points out that there are a few follow-up tasks after Phab:D5169: > > 1. We should build these at installation time, so they don't have to go into the binary distribution (the same goes for the vanilla way` libHSfoo.o` files) > 2. This also needs to be done in Hadrian > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #661: Serious Data.HashTable bug
by GHC 16 Jan '19

16 Jan '19

#661: Serious Data.HashTable bug -------------------------------------+--------------------------------- Reporter: jwr@… | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 6.4.2 Component: libraries/base | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | -------------------------------------+--------------------------------- Changes (by Matthew Pickering <matthewtpickering@…>): * failure: => None/Unknown Comment: In [changeset:"6486c6e49c53e75f37ed732b38c5be7ae64785e8/ghc" 6486c6e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6486c6e49c53e75f37ed732b38c5be7ae64785e8" Hadrian: Add support for building stage3 This ticket enables the building of a `stage3` compiler by making the build logic more consistent and predictable in Hadrian. Two of the main changes are: 1. In order to build anything at stageN we use the package database present at stageN. Fixing #16069 2. `haddock` and `ghc-tags` are built as stage1 executables (with the stage1 compiler) rather than as stage2 compiler. Fixing [hadrian#661](https://github.com/snowleopard/hadrian/issues/661) In order to build a stage3 compiler, you have to set the new `finalStage` hadrian option to `Stage3`. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/661#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure
by GHC 16 Jan '19

16 Jan '19

#16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am trying to build this library: https://github.com/GaloisInc/grift The build works perfectly on my Mac OS X system under ghc-8.4.4 via the README instructions. However, if I update to ghc-8.6.3, I get the following error: {{{ Building library for bv-sized-float-0.1.0.. [1 of 2] Compiling Data.BitVector.Sized.Float ( src/Data/BitVector/Sized/Float.hs, /Users/benselfridge/grift/dist- newstyle/build/x86_64-osx/ghc-8.6.3/bv-sized- float-0.1.0/build/Data/BitVector/Sized/Float.o ) [2 of 2] Compiling Data.BitVector.Sized.Float.App ( src/Data/BitVector/Sized/Float/App.hs, /Users/benselfridge/grift/dist- newstyle/build/x86_64-osx/ghc-8.6.3/bv-sized- float-0.1.0/build/Data/BitVector/Sized/Float/App.o ) ghc: loadArchive: Failed reading header from `/Users/benselfridge/grift /dist-newstyle/build/x86_64-osx/ghc-8.6.3/softfloat- hs-0.1.0/build/SoftFloat' ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): loadArchive "/Users/benselfridge/grift/dist- newstyle/build/x86_64-osx/ghc-8.6.3/softfloat-hs-0.1.0/build/SoftFloat": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The library "softfloat-hs" is a Haskell library that calls C functions that are dynamically linked. If I try to run it within this project via "cabal new-repl softfloat-hs", the dependency works fine. It's only when I try to build "bv-sized-float", which depends on softfloat-hs, that I get the above error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16063> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16069: Proposal to resolve some confusion about stages in Hadrian
by GHC 16 Jan '19

16 Jan '19

#16069: Proposal to resolve some confusion about stages in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- The current situation with hadrian is that 1. We build libraries required to build the stage2 compiler with stage1 and place them in `_build/stage1`. 2. The `stage2` compiler is built with `stage1` and then placed in `_build/stage1`. 3. Executables built using the `stage2` compiler such as haddock then also use the libraries built by the `stage1` compiler even though they are being built with the `stage2` compiler. However, this is problematic because when you want to build a `stage3` compiler, we want to actually build the libraries again using the `stage2` compiler and place them in `_build/stage2`. If we follow the existing logic for executables built using the `stage2` compiler then in order to build a `stage3` compiler we would just reuse all the libraries from `_build/stage1` which seems incorrect. The proposal is simply thus: 1. When building an executable at stageN, we use libraries also built at stageN. Concretely, if we want to build `haddock`, a stage2 executable, then we also have to build all the libraries it needs with the `stage2` compiler and install them into a package database in `_build/stage2`. 2. The definition of "build" can be configured. By default, in order to "build" a stage2 library we copy it from the stage1 database but it is configurable to rebuild it with the stage2 compiler as we would want to for stage3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15360: Template Haskell splicing drops lots of type arguments
by GHC 16 Jan '19

16 Jan '19

#15360: Template Haskell splicing drops lots of type arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | 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 conversion functions (in the `Convert` module) drop type arguments in various places. Here are two examples: {{{ data T a b c = Mk a b c bar :: $( return $ AppT (InfixT (ConT ''Int) ''T (ConT ''Bool)) (ConT ''Double) ) bar = Mk 5 True 3.14 }}} This correct code leads to an error {{{ Expecting one more argument to ‘T Int Bool’ }}} because the `Double` is forgotten. Similarly, {{{ baz :: $( return $ AppT (ParensT (ConT ''Maybe)) (ConT ''Int) ) baz = Just 5 }}} fails because `baz :: (Maybe)` isn't valid. On the other hand, {{{ frob :: forall (a :: $( [t| * Int |] )). a -> a frob x = x }}} is spuriously accepted, because GHC has forgotten about the `Int` argument. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns.
by GHC 15 Jan '19

15 Jan '19

#13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- GHC 8.0.2 and 8.2.1-rc1 (rc2 not checked) have a bug where -XApplicativeDo causes "GHC.Base.Monad.return" to be used instead of the locally available "return", and a spurious "return ()" shows up. This desugaring is not adhering to the -XRebindableSyntax spec (see: #12490). Example: {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RebindableSyntax #-} -- Bug vanishes if this next line is removed: {-# LANGUAGE ApplicativeDo #-} module Main where import Prelude (String, print) class MyFunctor f where fmap :: (a -> b) -> f a -> f b class MyApplicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b class MyMonad m where return :: a -> m a (>>) :: m a -> m b -> m b (>>=) :: m a -> (a -> m b) -> m b fail :: String -> m a join :: m (m a) -> m a testCase1 m1 m2 = do m1 m2 return () testCase2 m1 m2 = do _ <- m1 _ <- m2 return () main = print "42" }}} {{{ :t testCase1 testCase1 :: (MyFunctor f, MyApplicative f, MyMonad f, Monad f) => f a2 -> f a1 -> f () :t testCase2 :: testCase2 :: (MyFunctor f, MyApplicative f) => f t -> f a -> f () }}} The desugaring for testCase1 shows the issue: {{{#!hs testCase1' m1 m2 = (<*>) (fmap (\() () -> ()) (m1 >> (GHC.Base.Monad.return ()))) (m2 >> (GHC.Base.Monad.return ())) -- or: testCase1' m1 m2 = (fmap (\() () -> () ) (m1 >> (return ()))) <*> (m2 >> (return ())) }}} I would be able to work on this if someone pointed me in the right direction. It looks like it would be in `compiler/rename/RnEnv` and `compiler/rename/RnExpr`, as with #12490? As a proposed fix, I would want to implement a limited-scope fix before the 8.2.1 release which would not address the thornier issue of #10892. The patch would: 1. Replace `GHC.Base.Monad.return` with local `pure`, removing the `Monad` constraint. 2. Replace `>>` with `*>`, removing the `MyMonad` constraint. This isn't a _complete_ fix, as this would still induce an unnecessary use of the local `fmap`, but it would reduce the desugaring bug in `testCase1` to only that local `fmap`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16184: GHC said to report a bug
by GHC 15 Jan '19

15 Jan '19

#16184: GHC said to report a bug -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: panic, skolem | 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: -------------------------------------+------------------------------------- I tried to run {{{#!hs {-# LANGUAGE Rank2Types, PartialTypeSignatures #-} import Control.Monad newtype Search b = Search {optimum :: forall a. Ord a => (b -> a) -> b} instance Monad Search where return a = Search $ const a Search ma >>= f = Search $ \p -> optimum (f (ma (\a -> p (optimum (f a) p)))) p instance Functor Search where fmap = liftM instance Applicative Search where pure = return (<*>) = ap pair a b = Search $ \p -> if p a >= p b then a else b toList s = igo [] where igo ls = let x = optimum s (\x' -> x' `notElem` ls) in if x `elem` ls then ls else igo (x:ls) cantor :: Search (Integer -> Bool) cantor = let igo :: _ igo p n = q n (optimum cantor $ q n) where q n a = p undefined in Search igo main = return () }}} When run, it said {{{ source_file.hs:24:5: No instance for (Ord a) When checking that ‘igo’ has the specified type igo :: forall t a t1. (t -> a) -> t1 -> a Probable cause: the inferred type is ambiguous In the expression: let igo :: _ igo p n = q n (optimum cantor $ q n) where q n a = ... in Search igo In an equation for ‘cantor’: cantor = let igo :: _ igo p n = q n (optimum cantor $ q n) where ... in Search igo source_file.hs:26:15: Couldn't match type ‘t’ with ‘Integer -> Bool’ ‘t’ is untouchable inside the constraints (Ord a1) bound by a type expected by the context: Ord a1 => ((Integer -> Bool) -> a1) -> Integer -> Bool at source_file.hs:26:8-17ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): No skolem info: t_aU3[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Since it said to report a bug, I am. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16093: mkPluginUsage: file not found
by GHC 15 Jan '19

15 Jan '19

#16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | 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've been trying to track down another plugin issue when I ran into this one. I have the following `TestPlugin.hs` file: {{{#!hs module TestPlugin (plugin) where import GhcPlugins plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" return }}} And the following `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} They are both in the same directory. With ghc 8.4.2, I have: {{{ $ ghci-8.4.2 -package ghc Test.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, two modules loaded. }}} But with ghc 8.6.3, I get: {{{ $ ghci-8.6.3 -package ghc Test.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): mkPluginUsage: file not found TestPlugin ./TestPlugin.o Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} My original problem was different actually, so if you can suggest at least a workaround for this without actually fixing it I can proceed to replicate the other one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16093> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15831: DerivingVia allows bogus implicit quantification in `via` type
by GHC 14 Jan '19

14 Jan '19

#15831: DerivingVia allows bogus implicit quantification in `via` type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DerivingVia #-} {-# LANGUAGE PolyKinds #-} module Bug where import Data.Functor.Const (Const(..)) import GHC.Exts (Any) newtype Age = MkAge Int deriving Eq via Const Int Any }}} This fails to compile with a spectacularly unhelpful error message: {{{ $ /opt/ghc/8.6.1/bin/ghc -ddump-deriv Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ==================== Derived instances ==================== Derived class instances: instance GHC.Classes.Eq Bug.Age where (GHC.Classes.==) = GHC.Prim.coerce @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Age -> Bug.Age -> GHC.Types.Bool) (GHC.Classes.==) :: Bug.Age -> Bug.Age -> GHC.Types.Bool (GHC.Classes./=) = GHC.Prim.coerce @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Age -> Bug.Age -> GHC.Types.Bool) (GHC.Classes./=) :: Bug.Age -> Bug.Age -> GHC.Types.Bool Derived type family instances: Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ }}} There are two things that are strange here: * Notice that in the derived `Eq` instance, there are references to `(GHC.Types.Any :: k_a24l)`, where `k_a24l` is completely free! This should never happen, and is almost surely the cause of the resulting volley of errors. * It's quite odd that we didn't reject this `deriving` clause outright //before// generating the derived code. In fact, if we explicitly mention the kind `k`: {{{#!hs newtype Age = MkAge Int deriving Eq via Const Int (Any :: k) }}} //Then// it's rejected properly: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:12: error: Type variable ‘k’ is bound in the ‘via’ type ‘Const Int (Any :: k)’ but is not mentioned in the derived class ‘Eq’, which is illegal | 9 | deriving Eq | ^^ }}} Something about implicit quantification must be sneaking by this validity check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15831> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2