- ghc-tickets - Haskell.org

[GHC] #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints
by GHC 05 Jul '18

05 Jul '18

#15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE QuantifiedConstraints #-} module Bug where import Data.Kind data ECC :: Constraint -> Type -> Type class Y a class Z a instance c => Y (ECC c a) instance (c => Z a) => Z (ECC c a) }}} I would expect both of these instances to work. But while GHC accepts the `Y` instance, it rejects the `Z` instance: {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:10: error: • Variable ‘c’ occurs more often in the constraint ‘c’ than in the instance head (Use UndecidableInstances to permit this) • In the instance declaration for ‘Z (ECC c a)’ | 15 | instance (c => Z a) => Z (ECC c a) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} That error message seems completely bogus to me, since `c` appears once in both the context and instance head in both instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14883: QuantifiedConstraints don't kick in when used in TypeApplications
by GHC 05 Jul '18

05 Jul '18

#14883: QuantifiedConstraints don't kick in when used in TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | 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 program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Coerce import Data.Kind type Representational1 m = (forall a b. Coercible a b => Coercible (m a) (m b) :: Constraint) class Representational1 f => Functor' f where fmap' :: (a -> b) -> f a -> f b class Functor' f => Applicative' f where pure' :: a -> f a (<*>@) :: f (a -> b) -> f a -> f b class Functor' t => Traversable' t where traverse' :: Applicative' f => (a -> f b) -> t a -> f (t b) -- Typechecks newtype T1 m a = MkT1 (m a) deriving Functor' instance Traversable' m => Traversable' (T1 m) where traverse' :: forall f a b. (Applicative' f) => (a -> f b) -> T1 m a -> f (T1 m b) traverse' = coerce @((a -> f b) -> m a -> f (m b)) @((a -> f b) -> T1 m a -> f (T1 m b)) traverse' -- Doesn't typecheck newtype T2 m a = MkT2 (m a) deriving Functor' instance Traversable' m => Traversable' (T2 m) where traverse' = coerce @(forall f a b. Applicative' f => (a -> f b) -> m a -> f (m b)) @(forall f a b. Applicative' f => (a -> f b) -> T2 m a -> f (T2 m b)) traverse' }}} This defines a variant of `Functor` that has `forall a b. Coercible a b. Coercible (m a) (m b)` as a superclass, and also defines versions of `Applicative` and `Traversable` that use this `Functor` variant. This is towards the ultimate goal of defining `Traversable'` à la `GeneralizedNewtypeDeriving`. This attempt (using `InstanceSigs`) typechecks: {{{#!hs newtype T1 m a = MkT1 (m a) deriving Functor' instance Traversable' m => Traversable' (T1 m) where traverse' :: forall f a b. (Applicative' f) => (a -> f b) -> T1 m a -> f (T1 m b) traverse' = coerce @((a -> f b) -> m a -> f (m b)) @((a -> f b) -> T1 m a -> f (T1 m b)) traverse' }}} However, this version (which is closer to what `GeneralizedNewtypeDeriving` would actually create) does //not// typecheck: {{{#!hs newtype T2 m a = MkT2 (m a) deriving Functor' instance Traversable' m => Traversable' (T2 m) where traverse' = coerce @(forall f a b. Applicative' f => (a -> f b) -> m a -> f (m b)) @(forall f a b. Applicative' f => (a -> f b) -> T2 m a -> f (T2 m b)) traverse' }}} {{{ $ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:38:15: error: • Couldn't match representation of type ‘f1 (m b1)’ with that of ‘f1 (T2 m b1)’ arising from a use of ‘coerce’ NB: We cannot know what roles the parameters to ‘f1’ have; we must assume that the role is nominal • In the expression: coerce @(forall f a b. Applicative' f => (a -> f b) -> m a -> f (m b)) @(forall f a b. Applicative' f => (a -> f b) -> T2 m a -> f (T2 m b)) traverse' In an equation for ‘traverse'’: traverse' = coerce @(forall f a b. Applicative' f => (a -> f b) -> m a -> f (m b)) @(forall f a b. Applicative' f => (a -> f b) -> T2 m a -> f (T2 m b)) traverse' In the instance declaration for ‘Traversable' (T2 m)’ • Relevant bindings include traverse' :: (a -> f b) -> T2 m a -> f (T2 m b) (bound at Bug.hs:38:3) | 38 | traverse' = coerce @(forall f a b. Applicative' f => (a -> f b) -> m a -> f (m b)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} Shouldn't it, though? These instance declarations out to be equivalent (morally, at least). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15344: ApplicativeDo seems to prevent the fail method from being used
by GHC 05 Jul '18

05 Jul '18

#15344: ApplicativeDo seems to prevent the fail method from being used -------------------------------------+------------------------------------- Reporter: kccqzy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I am not sure if this is intended, but I came across this issue when debugging a runtime exception. It seems like an incomplete pattern match in a do-block with ApplicativeDo enabled will not use the fail method. If I have a module like this {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# OPTIONS_ghc -ddump-simpl #-} module M where f :: Maybe (Maybe Int) -> Maybe Int -> Maybe Int f mgs mid = do _ <- mid (Just moi) <- mgs pure (moi + 42) main :: IO () main = print (f (Just Nothing) (Just 2)) }}} This will result in a runtime exception: {{{ Just *** Exception: repro.hs:(6,13)-(9,17): Non-exhaustive patterns in lambda }}} But if I remove the ApplicativeDo extension, this code works as normal, producing Nothing as the output. On a theoretical level I understand why this is happening, but I still find it quite unexpected, especially since the documentation at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #things-to-watch-out-for claims that > Your code should just work as before when ApplicativeDo is enabled, provided you use conventional Applicative instances. If this is not a defect in GHC itself, I'd say it is a defect in documentation in not pointing out this gotcha. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11547: Accessing shadowed definitions in GHCi
by GHC 05 Jul '18

05 Jul '18

#11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- Apparently GHCi creates a qualified namespace for each line it interprets, as can be observed with: {{{#!hs > data A = A > data A = B > :t A A :: Ghci3.A }}} Apparently accessing shadowed definitions in this way sometimes breaks GHCi: {{{#!hs > let a = a > let a = a > :t Ghci7.a <interactive>:1:1: error: • GHC internal error: ‘Ghci7.a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the expression: Ghci7.a }}} More specifically, complete reproduction instructions: {{{#!hs GHCi, version 8.1.20160205: http://www.haskell.org/ghc/ :? for help > let foo = foo > :t Ghci1.foo Ghci1.foo :: t > let foo = foo > :t Ghci1.foo <interactive>:1:1: error: • GHC internal error: ‘Ghci1.foo’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the expression: Ghci1.foo }}} 7.10.2 (and 7.8.3 as verified over IRC by monochrom) appears to have a slightly different behavior. It seems it only creates namespaces for data/newtype/class declarations. Yet still, it fails with an error the first time but works completely fine thereafter: {{{#!hs > data A = A > data A = A > :t Ghci1.A Failed to load interface for ‘Ghci1’ no package key matching ‘interactive’ was found > :t Ghci1.A Ghci1.A :: Ghci1.A }}} 7.6.3 uses a different approach to displaying out of scope names so the behavior doesn't apply: {{{#!hs > data A = A > data A = B > :t A A :: main::Interactive.A }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8263: allow duplicate deriving / standalone deriving
by GHC 04 Jul '18

04 Jul '18

#8263: allow duplicate deriving / standalone deriving ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I would like to avoid conditional compilation. Currently I need to write: {{{ #if MIN_VERSION_Cabal(1,18,0) -- cabal 1.18 has these instances #else deriving instance Typeable Flag #endif }}} Would it be sane to have the deriving instance do nothing if the imported instance that clashes was also derived? reifyInstances together with a fixed #8100 could allow faking this feature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15202: Internal error showing typed hole in GHCi
by GHC 04 Jul '18

04 Jul '18

#15202: Internal error showing typed hole in GHCi -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypedHoles | 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: -------------------------------------+------------------------------------- Run `ghc --interactive`, and at the prompt type {{{#!hs default () fish :: Eq a => a; fish = undefined foo :: String; foo = show _ }}} The following error appears: {{{ <interactive>:1:1: error: GHC internal error: ‘Ghci1.$trModule’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r2CZ :-> Identifier[foo::String, TopLevelLet]] }}} I have not yet been able to reproduce this loading a module; it seems to need to be on the command line. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers
by GHC 04 Jul '18

04 Jul '18

#15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let x = () Prelude> let x = () Prelude> :t _ <interactive>:1:1: error: GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] }}} Seems to only happen when there were two identifiers defined with the same name. As verified by mpickering on IRC this isn't reproducible in 8.2.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jul '18

04 Jul '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): New nofib results. - `nofib-gn-gnl`: GHC and boot libraries compiled with `-fno-state-hack` compiling nofib normally, vs. GHC compiled normally and boot libraries compiled with `-fno-state-hack` compiling nofib normally. This measures the effect of compiling GHC itself with `-fno-state-hack`. - `nofib-ns-nn`: GHC compiled normally compiling nofib normally vs. GHC compiled normally compiling nofib with `-fno-state-hack`. This measures the effect of the state hack on nofib when using a vanilla compiler. - `nofib-ns-nn-gnl`: GHC compiled normally with boot libraries compiled with `-fno-state-hack` compiling nofib normally vs. GHC compiled normally with boot libraries compiled with `-fno-state-hack` compiling nofib with `-fno-state-hack`. This measures the effect of the state hack on nofib when using a vanilla compiler with state-hack-free boot libraries. Key observations: - Differences are now much closer to what we expect, specifically, whether we compile GHC and / or boot libraries with or without the state hack does not significantly change nofib performance (< 1%). - Compiling GHC itself and boot libraries without the state hack makes nofib compilation slightly slower than compiling only boot libraries without the state hack (~4%). - Compiling nofib without the state hack makes compilation significantly faster (~25%) than compiling nofib with the state hack, regardless of how GHC itself and the boot libraries were compiled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jul '18

04 Jul '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-ns-nn-gnl.analyze.log" added. nofib analyse output: nofib compiled with NSH vs. normally, on a GHC build with NSH libraries -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jul '18

04 Jul '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-ns-nn.analyze.log" added. nofib analyse output: nofib compiled with NSH vs. normally, on a vanilla GHC build -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0