- ghc-tickets - Haskell.org

[GHC] #16247: GHC 8.6 Core Lint regression (Kind application error)
by GHC 12 Feb '19

12 Feb '19

#16247: GHC 8.6 Core Lint regression (Kind application error) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- The following program produces a Core Lint error on GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data SameKind :: forall k. k -> k -> Type data Foo :: forall a k (b :: k). SameKind a b -> Type where MkFoo :: Foo sameKind }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of CorePrep *** <no location info>: warning: In the type ‘forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind’ Kind application error in type ‘SameKind a_aWE b_aWG’ Function kind = forall k. k -> k -> * Arg kinds = [(k_aWF, *), (a_aWE, k_aWD), (b_aWG, k_aWF)] Fun: k_aWF (a_aWE, k_aWD) *** Offending Program *** <elided> MkFoo :: forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind }}} (Confusingly, the type of `MkFoo` is rendered as `forall k (a :: k) k (b :: k) (sameKind :: SameKind a b). Foo sameKind` in that `-dcore-lint` error, but I think it really should be `forall k1 (a :: k1) k2 (b :: k2) (sameKind :: SameKind a b). Foo sameKind`.) On GHC 8.4.4 and earlier, this simply produces an error message: {{{ $ /opt/ghc/8.4.4/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:13: error: • These kind and type variables: a k (b :: k) are out of dependency order. Perhaps try this ordering: k (a :: k) (b :: k) • In the kind ‘forall a k (b :: k). SameKind a b -> Type’ | 9 | data Foo :: forall a k (b :: k). SameKind a b -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16305: When should -Wmissed-specializations fire?
by GHC 12 Feb '19

12 Feb '19

#16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | 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: -------------------------------------+------------------------------------- While working on a fix for #16282, I noticed: 1. that `-Wmissed-specializations` doesn't fire when the docs say it should 2. that the "probable fix" suggested when a warning does fire is highly suspect {{{ import Data.Map main :: IO () main = do let m = [] :: [Map String Bool] mapM_ print m }}} With GHC 8.4.3, 8.6.3, and HEAD: `ghc -O2 -Wmissed-specializations Main.hs` does *not* issue any warnings. However, `ghc -O2 -Wall-missed-specializations Main.hs` *does* create a warning: {{{ Main.hs: warning: [-Wall-missed-specialisations] Could not specialise imported function ‘Data.Map.Internal.$w$cshowsPrec’ when specialising ‘Data.Map.Internal.$fShowMap_$cshowsPrec’ Probable fix: add INLINABLE pragma on ‘Data.Map.Internal.$w$cshowsPrec’ }}} The docs for `-Wmissed-specializations` say, "warn when specialisation of an imported, overloaded function fails." Since `showsPrec` is an imported function, it seems that a warning should have been issued with `-Wmissed- specs`. My reading of the docs is that `-Wall-missed-specs` should output everything `-Wmissed-specs` does, along with any *local* overloaded and unspecialized functions. Moreover, the "Probable fix" is suspect. A warning recommending an `INLINABLE` pragma is issued depending on the output of `warnMissedSpec` in specialise/Specialise.hs. For `-Wall-missed-specs`, `warnMissedSpec` doesn't check if an INLINABLE pragma is already present, so the fix could be redundant. For `-Wmissed-specs`, `warnMissedSpecs` *only* issues a warning if there *is* any inline pragma (of one sort of another) on all the callers, making the `probable fix` definitely redundant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16309: Flag to instruct GHC not to use an environment file
by GHC 12 Feb '19

12 Feb '19

#16309: Flag to instruct GHC not to use an environment file -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- As the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.ht… #package-environments user manual] document, GHC looks for environment files in the current directory to tell it what packages to look for. There seems to be no way to disable this behavior (short of deleting or renaming the environment file). This causes trouble for me, as I expect `ghci` to mean the same thing no matter where I say it. Can we add a flag (perhaps `-no-package-env`) that tells GHC not to look for an environment file? Note that specifying a dummy package environment file doesn't work because we can't suppress the implicit `-hide-all- packages` that is triggered whenever using a package environment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16308: testsuite driver is sensitive to registration of multiple boot package versions
by GHC 12 Feb '19

12 Feb '19

#16308: testsuite driver is sensitive to registration of multiple boot package versions -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- Currently `testsuite/tests/Makefile` generates the `--rootdir` flags to be passed by `runtests.py` by looking at the output of `ghc-pkg list`. In the case that the user has recently bumped their submodules this list may contain multiple versions of the same package. This will then result in the same `library/$LIB/tests` directory being passed to the testsuite driver more than once. The testsuite driver will then squawk a "There are multiple tests with this name" warning. It took a few minutes for Simon and I to work out why this was. We should do better here (at least in Hadrian). Either by: * Teaching the testsuite driver to deduplicate the `--rootdir` list * Using a more robust source for the list of tested packages -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16051: Cross compilation broken under Hadrian
by GHC 12 Feb '19

12 Feb '19

#16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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: -------------------------------------+------------------------------------- Hadrian falls over essentially immediately when cross-compiling: {{{ $ ./boot $ ./configure --target=aarch64-linux-gnu $ hadrian/build.cabal.sh -j32 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16073: Hadrian build fails on Windows
by GHC 12 Feb '19

12 Feb '19

#16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See https://gitlab.haskell.org/ghc/ghc/-/jobs/2838. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16075: OPTIONS_GHC Ignored
by GHC 12 Feb '19

12 Feb '19

#16075: OPTIONS_GHC Ignored -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I enable `-Weverything`, some `OPTIONS_GHC` pragmas are respected, while others are ignored. For example, with `-Weverything`, this file {{{ main = print "hello" foo :: (Num a, Show a) => a -> IO () foo = print . show }}} generates warnings about: 1. missing an export list 2. top-level binding [main] with no type sig 3. redundant constraint [Num a] If I add `{-# OPTIONS_GHC -fno-warn-missing-signatures -fno-warn-missing- export-lists -fno-warn-redundant-constraints #-}` to the top of the file and recompile, I expect all warnings to go away. But GHC still reports that `main` has no signature. Note that this problem doesn't occur with `-Wall`. With `-Wall`, the code snippet warns about the missing signature on `main`, but when I add the `OPTIONS_GHC`, the warning goes away. Thus this problem appears to be unique to `Weverything`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16300: Make TH always reify data types with explicit return kinds
by GHC 11 Feb '19

11 Feb '19

#16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.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: -------------------------------------+------------------------------------- Currently, whenever you reify a data type with Template Haskell, it will return a `DataD`/`NewtypeD` where the return kind information has been set to `Nothing`: {{{ λ> putStrLn $(reify ''Bool >>= stringE . show) TyConI (DataD [] GHC.Types.Bool [] Nothing [NormalC GHC.Types.False [],NormalC GHC.Types.True []] []) }}} One could argue that this isn't a problem since data types always have return kind `Type` anyway. For 99% of data types, this is true. There are a handful of exceptions, such as unboxed tuples (with return kind `TYPE (TupleRep [...])`, but those could be dismissed as unusual special cases. With the advent of [https://phabricator.haskell.org/D4777 unlifted newtypes], however, things become murkier. `UnliftedNewtypes` let you define newtypes like this one: {{{#!hs newtype Foo :: TYPE IntRep where MkFoo :: Int# -> Foo }}} Notice how the return kind is //not// `Type`, but instead `TYPE IntRep`. However, TH reification doesn't clue you in to this fact: {{{ λ> putStrLn $(reify ''Foo >>= stringE . show) TyConI (NewtypeD [] Ghci8.Foo [] Nothing (GadtC [Ghci8.MkFoo] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Prim.Int#)] (ConT Ghci8.Foo)) []) }}} Still `Nothing`. There's no easy way in general to determine what the return kind of an unlifted newtype is using TH reification, which is unfortunate. Luckily, I think there's a very simple fix that we could apply here: just have TH reification return `Just (<kind>)` instead of `Nothing`! There's no technical reason why TH couldn't do this; the only reason it currently returns `Nothing` is due to historical convention. Moreover, I doubt that this would even break any code in the wild, since `Nothing` doesn't convey any useful information in the context of TH reification anyway. Does this sound reasonable? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed`
by GHC 11 Feb '19

11 Feb '19

#15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: base, | Operating System: Unknown/Multiple Data.Fixed | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello; I'm creating this email to propose a change to `Data.Fixed`. Full credit for this idea goes to Bhavik Mehta (@b-mehta on GitHub), who implemented it in this [https://github.com/dmcclean/exact-pi/pull/8 PR] for `exact- pi`. In `Data.Fixed` there are several `E`-prefixed datatypes used to represent a certain number of digits of precision in fixed-precision arithmetic. For example, `E1` has 1 decimal place, `E12` has 12. Each of them, `E{0,1,2,3,6,9,12}` is hardcoded. If more precision types are to be provided, they have to be hardcoded as well, and all of these types resemble each other. I think there is room for improvement here. Instead of having {{{#!hs data E0 instance HasResolution E0 where resolution _ = 1 }}} and repeating it as many times as there are `E` datatypes, I propose to add the following type: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} import GHC.TypeLits (Nat, KnownNat, natVal) data E (n :: Nat) }}} and then do {{{#!hs instance KnownNat n => HasResolution (E n) where resolution _ = 10^natVal (undefined :: E n) }}} just once, replacing `data E0` with `type E0 = E 0` (and the same for the rest of them) to continue reexporting these types. `E` should also be exported. I've sent an email to the Core Libraries Committee regarding this issue. This is my first contribution to GHC, if I'm doing something incorrectly please tell me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

Re: [GHC] #7679: Regression in -fregs-graph performance
by GHC 11 Feb '19

11 Feb '19

#7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanessamchale): * cc: vanessa.mchale@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7679#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0