June 2018 - ghc-tickets

[GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind
by GHC 07 Jun '18

07 Jun '18

#15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- The following program typechecks on GHC 8.2.2 and 8.4.2: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Void infixl 4 :== -- | Heterogeneous Leibnizian equality. newtype (a :: j) :== (b :: k) = HRefl { hsubst :: forall (c :: forall (i :: Type). i -> Type). c a -> c b } newtype Coerce a = Coerce { uncoerce :: Starify a } type family Starify (a :: k) :: Type where Starify (a :: Type) = a Starify _ = Void coerce :: a :== b -> a -> b coerce f = uncoerce . hsubst f . Coerce }}} But GHC HEAD rejects it: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:21:34: error: • Kind mismatch: cannot unify (c0 :: forall i. i -> *) with: Coerce :: forall k. k -> * Their kinds differ. Expected type: a -> c0 * a Actual type: Starify a -> Coerce a • In the second argument of ‘(.)’, namely ‘Coerce’ In the second argument of ‘(.)’, namely ‘hsubst f . Coerce’ In the expression: uncoerce . hsubst f . Coerce | 21 | coerce f = uncoerce . hsubst f . Coerce | ^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15188: Catch cases where both branches of an if jump to the same block.
by GHC 07 Jun '18

07 Jun '18

#15188: Catch cases where both branches of an if jump to the same block. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For one reason or the other sometimes we end up with if statements in Cmm where both branch targets are the same: Actual example from NoFib: {{{ u9oL: if (_c9oA::P64 != 5) goto u9p2; else goto u9p2; }}} Which eventually results in this code: {{{ _u9oL: cmpq $5,%rbx jne _u9p2 <- utterly pointless _u9p2: addq $16,%rbp jmp _c9iq }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15238: T13838 fails in ghci way
by GHC 07 Jun '18

07 Jun '18

#15238: T13838 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: -------------------------------------+------------------------------------- {{{ Wrong exit code for T13838(ghci) (expected 1 , actual 0 ) Stderr ( T13838 ): T13838:6:30: error: • Couldn't match expected type ‘IO a0’ with actual type ‘() -> ()’ • Probable cause: ‘main’ is applied to too few arguments In the first argument of ‘GHC.TopHandler.runIOFastExit’, namely ‘main’ In the first argument of ‘(>>)’, namely ‘GHC.TopHandler.runIOFastExit main’ In the expression: GHC.TopHandler.runIOFastExit main >> return () *** unexpected failure for T13838(ghci) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ...
by GHC 07 Jun '18

07 Jun '18

#12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.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: -------------------------------------+------------------------------------- {{{ >>> import GHC.Prim >>> :bro GHC.Prim [...] type role (~#) nominal nominal data (~#) (t3 :: a) (t4 :: b) type role ~P# phantom phantom data ~P# (t3 :: a) (t4 :: b) type role (~R#) representational representational data (~R#) (t3 :: a) (t4 :: b) }}} getting the kind of `~`, `~#`, `~~` works fine: {{{ >>> import GHC.Prim >>> import GHC.Types >>> :kind (~) (~) :: k -> k -> Constraint >>> :kind (~#) (~#) :: a -> b -> TYPE 'VoidRep >>> :kind (~~) (~~) :: j -> k -> Constraint }}} but `#` gets incorrectly treated as an operator in `~R#` and `~P#`: {{{ >>> :kind (~R#) <interactive>:1:3: error: Illegal operator ‘#’ in type ‘~R #’ Use TypeOperators to allow operators in types <interactive>:1:3: error: Operator applied to too few arguments: ~R # <interactive>:1:4: error: Not in scope: type constructor or class ‘R’ }}} Furthermore while running `:info` on `~~` and `~#` works fine {{{ >>> :info (~~) class a ~# b => (~~) (a :: j) (b :: k) -- Defined in ‘GHC.Types’ >>> :info (~#) type role (~#) nominal nominal data (~#) (t3 :: a) (t4 :: b) -- Defined in ‘GHC.Prim’ }}} the others don't parse {{{ >>> :info (~) <interactive>:1:2: error: parse error on input ‘~’ >>> :info (~R#) <interactive>:1:2: error: parse error on input ‘~’ >>> :info (~P#) <interactive>:1:2: error: parse error on input ‘~’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15236: GHCi pretty-prints (->)'s fixity poorly
by GHC 07 Jun '18

07 Jun '18

#15236: GHCi pretty-prints (->)'s fixity poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: -------------------------------------+------------------------------------- Consider the following GHCi session: {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :i (->) data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’ infixr 0 `(->)` <instances elided> }}} Notice that it prints: {{{ `(->)` }}} Which is totally wrong. This should simply be `->`. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2
by GHC 07 Jun '18

07 Jun '18

#15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 -------------------------------------+------------------------------------- Reporter: fsoikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple CustomTypeErrors | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program compiles fine on GHC 8.0.2, but GHC 8.2.2 issues a warning, complaining that `TypeError` is a redundant constraint. This makes it very inconvenient to use `TypeError` with type classes. {{{#!hs {-# OPTIONS_GHC -Wredundant-constraints -Wall -Werror #-} import GHC.TypeLits (TypeError, ErrorMessage(..)) class C a where f :: a -> a instance {-# OVERLAPPING #-} C Int where f _ = 42 instance {-# OVERLAPPABLE #-} TypeError ( 'Text "Only Int is supported" ) => C a where f = undefined main :: IO () main = print $ f (42::Int) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc
by GHC 07 Jun '18

07 Jun '18

#15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: plugins | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4792 | Wiki Page: -------------------------------------+------------------------------------- The primary motivation for this is that this allows users to access the warnings and error machinery present in TcM. However, it also allows users to use TcM actions which means they can typecheck GhcPs which could be significantly easier than constructing GhcTc. See https://phabricator.haskell.org/D4792 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15212: powerpc64le-unknown-linux is missing from llvm-targets
by GHC 07 Jun '18

07 Jun '18

#15212: powerpc64le-unknown-linux is missing from llvm-targets ---------------------------------+--------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------- T5681 fails with: Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180531 for powerpc64le-unknown-linux): Failed to lookup the datalayout for powerpc64le-unknown-linux; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unkno wn-linux-gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux- gnueabihf","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux- gnueabihf","aarch64-unknown-linux-gnu","aarch64-unknown-linux","i3 86-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown-linux- gnu","x86_64-unknown-linux","armv7-unknown-linux-androideabi","aarch64 -unknown-linux-android","arm-unknown-nto-qnx-eabi","i386-apple-darwin ","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple-ios","i386-apple- ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15212> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends
by GHC 07 Jun '18

07 Jun '18

#14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: ghc-pkg | Version: 8.2.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 GHC 8.2, we introduced `abi-depends` to solve #12485. Following the same pattern as all ghc-pkg fields, this field is to be fllled by whoever is performing the registration. I now suspect designing it this way was a mistake. In https://github.com/haskell/cabal/issues/4728 we have a bug where Cabal is writing nonsense data for `abi-depends`, `ghc-pkg` isn't noticing it, and GHC is rejecting the package (with a "shadow" warning) when it gets to the end. The problem is the Cabal aggressively caches the contents of the package database (ostensibly because it is expensive to query `ghc-pkg`); this means that it is easy to get into a situation where its understanding of the ABIs of its dependencies is out-of-date (because it is not re- reading the database in order to get newer information). The insult to the injury is, in most cases, ghc-pkg already knows what the ABIs are supposed to be: they're whatever the ABIs of the packages pointed at by 'depends' already in the database are. So ghc-pkg could have computed the abi dependency itself, and prevented this stale data situation from ever happening. This sounds quite attractive to me. What do people think? Here is one possible proposal (but it is just one in the space): * `ghc-pkg` will be modified to ignore the `abi-depends` field (perhaps with a warning), to prevent itself from being poisoned by buggy versions of Cabal which are giving bad ABI information * Instead, `ghc-pkg` generates the `abi-depends` field by looking up dependency IDs from the database. If an ID is not found, it omits the dep from `abi-depends` (this is equivalent to suspending ABI checking in GHC, so this won't break anything; it will just make ABI checking less robust) * Possibly, introduce a new "virtual" field, which can be used to override `ghc-pkg` default -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13438: ghci :browse does not work with DuplicateRecordFields
by GHC 07 Jun '18

07 Jun '18

#13438: ghci :browse does not work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple duplicaterecordfields ghci | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using `:browse` on module which has enabled DuplicateRecordFields and datatypes are exported, does not return the field accessor functions. So for example: {{{#!hs data Login = Login { code :: Text , password :: Text } )}}} `browse` for module does not return `code` and `password` accessor functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3