November 2018 - ghc-tickets

[GHC] #15850: coercion errors don't always mention that data constructors are not in scope
by GHC 02 Nov '18

02 Nov '18

#15850: coercion errors don't always mention that data constructors are not in scope -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 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: -------------------------------------+------------------------------------- Suppose a library defines a `newtype` with a `nominal` type parameter: {{{#!hs {-# LANGUAGE RoleAnnotations #-} module Lib where type role LibIdentity nominal newtype LibIdentity a = LibIdentity a }}} (in my code, that `newtype` is `ExceptT`, whose last argument is inferred to be `nominal`) In a different module, I also define a `newtype`, and then I try to use `coerce` to remove some of the `newtype` wrappers. Unfortunately I forgot to import `LibIdentity`'s data constructor, and so the coercions fail. Sometimes, the error message helpfully explains that I need that import... but sometimes it doesn't! {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Local where import Data.Coerce (coerce) import Lib (LibIdentity) newtype LocalIdentity a = LocalIdentity a -- error: -- • Couldn't match representation of type ‘()’ -- with that of ‘LibIdentity ()’ -- arising from a use of ‘coerce’ -- The data constructor ‘Lib.LibIdentity’ -- of newtype ‘LibIdentity’ is not in scope helpfulError :: LocalIdentity (LibIdentity ()) -> LocalIdentity () helpfulError = coerce -- error: -- • Couldn't match type ‘LocalIdentity ()’ with ‘()’ -- arising from a use of ‘coerce’ difficultError :: LibIdentity (LocalIdentity ()) -> LibIdentity () difficultError = coerce }}} Expected: both uses of `coerce` remind me to import the data constructor of `LibIdentity`. Observed: only `helpfulError` reminds me, while `difficultError` doesn't. (in my code, the `coerce` is generated by `GeneralizedNewtypeDeriving` and the error message does not include the type whose data constructor needs to be imported, making it quite difficult to guess how to fix the error) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15850> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15803: Put more info with flag description
by GHC 02 Nov '18

02 Nov '18

#15803: Put more info with flag description -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- In the user manual, consider flag `-fcase-folding`. * It appears in [http://downloads.haskell.org/~ghc/master/users- guide/flags.html#individual-optimisations this table] where we learn that it is implied by `-O`. * But if you click on the flag name to [http://downloads.haskell.org/~ghc/master/users-guide/using- optimisation.html#ghc-flag--fcase-folding get more detail here], we no longer see that it's implied by -O. We just see that it defaults "on" which suggests it might be on with -O0. The source material, in `using-optimisation.rst` looks like this {{{ .. ghc-flag:: -fcase-folding :shortdesc: Enable constant folding in case expressions. Implied by :ghc-flag:`-O`. :type: dynamic :reverse: -fno-case-folding :category: :default: on Allow constant folding in case expressions that scrutinise some primops: }}} I think that in the "more details" page we should definitely display the "implied by -O" part, and the "reverse flag". Could we do that? I'm not sure about the "default". It's bizarre to be implied by -O but by-default on! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15815: problem with splicing type into constraint
by GHC 02 Nov '18

02 Nov '18

#15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.1 Haskell | 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: -------------------------------------+------------------------------------- Consider the following two-module example. (as gist: https://gist.github.com/int-e/a666991423c10150bd99dd0e874d6150) {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where mkFoo tyQ = [d| foo :: a ~ $(tyQ) => a foo = undefined |] }}} {{{#!hs {-# LANGUAGE TemplateHaskell, GADTs #-} module B where import A mkFoo [t| Int -> Int |] }}} This loads fine in ghc-8.4.2, but with ghc-8.6.1 and current head (commit 578012be13eb1548050d51c0a23bd1a98423f03e), the splice goes wrong: {{{ $ ghci B.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) B.hs:7:1: error: • Expected a type, but ‘a_a4uD ~ Int’ has kind ‘Constraint’ • In the type signature: foo :: a_a4uD ~ Int -> Int => a_a4uD | 7 | mkFoo [t| Int -> Int |] | ^^^^^^^^^^^^^^^^^^^^^^^ Failed, one module loaded. *A> }}} As a workaround one can define a type alias for the `Int -> Int` type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness
by GHC 02 Nov '18

02 Nov '18

#14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: #7210 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data A = A { a :: {-# UNPACK #-} Maybe Int} }}} {{{ [1 of 1] Compiling Main ( Temp.hs, Temp.o ) Temp.hs:1:19: error: • Unexpected strictness annotation: {-# UNPACK #-}Maybe • In the type ‘{-# UNPACK #-}Maybe Int’ In the definition of data constructor ‘A’ In the data declaration for ‘A’ | 1 | data A = A { a :: {-# UNPACK #-} Maybe Int} | }}} The diagnostic is incorrect because it complains about an "unexpected strictness annotation" although the error is the opposite. A quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level
by GHC 01 Nov '18

01 Nov '18

#15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- A file A defines a typeclass, and gives an instance for all types a, and exports a function relying on said typeclass. A file B defines a data type, makes it a specific `OVERLAPPING` instance of that class, and uses the function defined in A. Which instance ends up being picked for B depends on the optimisation level those files are compiled with. **Minimal test case** //A.hs// {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# OPTIONS_GHC -fno-warn-simplifiable-class-constraints #-} module A where import Data.Maybe class A a where someValue :: a -> Maybe Int instance A a where someValue = const Nothing getInt :: A a => a -> Int getInt x = fromMaybe 0 $ someValue x }}} //B.hs// {{{#!hs module B where import A data B = B Int instance {-# OVERLAPPING #-} A B where someValue (B x) = Just x getBInt :: Int getBInt = getInt $ B 42 }}} //Main.hs// {{{#!hs import B main :: IO () main = putStrLn $ "B: " ++ show getBInt }}} To reproduce: {{{ $ ghc -O0 -fforce-recomp Main.hs && ./Main [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... B: 42 $ ghc -O2 -fforce-recomp Main.hs && ./Main [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... B: 0 }}} The fix introduced to fix ticket:14434 instructs the "short-cut solver" to not automatically choose a matching instance if it marked as `INCOHERENT` or `OVERLAPPABLE`, but in this case the instance is not marked in any way. This might be the source of the bug? Additionally, whatever the optimisation level, ghc emits a warning about the `A a =>` class constraint being simplifiable; but if it is removed, then the program prints "0" in both cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15654: Use deriving Functor in the codebase
by GHC 01 Nov '18

01 Nov '18

#15654: Use deriving Functor in the codebase -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- In many places in compiler/ we manually define a Functor instance (`git grep "instance Functor"` shows 60). I think we could switch to `deriving` in most (or all?) cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15821: Implement constant folding for Naturals
by GHC 01 Nov '18

01 Nov '18

#15821: Implement constant folding for Naturals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #14465 has already gone a long way in improving the runtime performance of `Natural` numbers. However, we still lack constant folding for these numbers so there is money left on the table. To fix this you will want to implement rules similar to those for `Integer` in the `PrelRules` module. Additionally, you will need to comment back in the `CONSTANT_FOLDED` pragmas in `GHC.Natural` (see Phab:D5267) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15821> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4