January 2016 - ghc-tickets

[GHC] #11062: Type families + hs-boot files = panic
by GHC 09 Feb '17

09 Feb '17

#11062: Type families + hs-boot files = panic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 have these modules: A.hs-boot: {{{ {-# LANGUAGE TypeFamilies #-} module A where type family F a }}} B.hs: {{{ {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A type instance F Int = Bool }}} A.hs: {{{ {-# LANGUAGE TypeFamilies #-} module A where import B type family F a }}} And now this happens: {{{ rae:11:50:47 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 7.11.20151104 rae:11:50:50 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c A .hs-boot rae:11:50:52 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c B.hs rae:11:50:54 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c A.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151104 for x86_64-apple-darwin): tcIfaceGlobal (local): not found: F [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rae:11:50:57 ~/temp/bug> }}} The problem occurs only in one-shot mode. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8155: Defaulting bug or unfortunate error message with closed type families
by GHC 08 Feb '17

08 Feb '17

#8155: Defaulting bug or unfortunate error message with closed type families ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- https://github.com/nh2/infinite-type-families/blob/master/Test2.hs Some code extracted from hmatrix: {{{ {-# LANGUAGE CPP #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module Test where data Vector a = Vector a data Matrix a = Matrix a class Build f where build' :: BoundsOf f -> f -> ContainerOf f #if __GLASGOW_HASKELL__ <= 706 -- Normal type families with GHC 7.6, works well. type family BoundsOf x type instance BoundsOf (a->a) = Int type instance BoundsOf (a->a->a) = (Int,Int) type family ContainerOf x type instance ContainerOf (a->a) = Vector a type instance ContainerOf (a->a->a) = Matrix a #else -- Closed type families for GHC 7.8 type family BoundsOf x where BoundsOf (a->a->a) = (Int,Int) BoundsOf (a->a) = Int type family ContainerOf x where ContainerOf (a->a) = Vector a ContainerOf (a->a->a) = Matrix a #endif instance (Num a) => Build (a->a) where build' = buildV buildV :: (Integral a, Num b) => a -> (b -> c) -> Vector c buildV _ _ = undefined }}} This is probably related to #8154. With GHC 7.7, we get the following error: {{{ Test2.hs:59:14: Could not deduce (BoundsOf (a -> a) ~ Integer) from the context (Num a) bound by the instance declaration at Test2.hs:58:10-32 Expected type: BoundsOf (a -> a) -> (a -> a) -> ContainerOf (a -> a) Actual type: Integer -> (a -> a) -> Vector a Relevant bindings include build' :: BoundsOf (a -> a) -> (a -> a) -> ContainerOf (a -> a) (bound at Test2.hs:59:5) In the expression: buildV In an equation for ‛build'’: build' = buildV }}} 1) Where does this Integer come from? 2) Change {{{ BoundsOf (a->a) = Int }}} into {{{ BoundsOf (a->a) = Integer }}} You get the same error message, although clearly {{{BoundsOf (a -> a) ~ Integer}}} (you just wrote that down).[[BR]] Even if the order matters in closed type families, is this not the wrong error message? 3) If you flip the order so that the (a->a) case comes first, it works (with both it Int or Integer). I don't quite understand why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall
by GHC 07 Feb '17

07 Feb '17

#10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: Incorrect Keywords: | warning at compile-time Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I compile existing code with GHC-7.11.20150707 I get lot of "redundant constraints" warnings. Generally I think that this warning can be very useful for minimizing constraints, nonetheless there are good reasons not choose minimal constraints for a type signature. E.g. if I have to implement `Data.Map.singleton` I do not need the `Ord k` constraint for the key type. However, I might add it anyway in order to be able to change the implementation in future such that it uses `Ord k` dictionary. Thus I suggest to exclude `-fwarn-redundant-constraints` from `-Wall`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #10823: Expose keepAlive to Template Haskell
by GHC 03 Feb '17

03 Feb '17

#10823: Expose keepAlive to Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{keepAlive}}} is a [https://github.com/ghc/ghc/blob/efa7b3a474bc373201ab145c129262a73c86f959/co… function in TcRnMonad] that adds a {{{Name}}} to the set of {{{Name}}}s to keep when pruning out dead code. A concrete use case for exposing this to Template Haskell is in LiquidHaskell, which will soon function as a Core plugin. In LiquidHaskell, a subset of Haskell functions can be "lifted" to the logic level and used in types. For example: {{{ module Test (ok) where [lq| inline gt |] gt x y = x > y [lq| ok :: x:Int -> { v:Int | gt x v } |] ok x = x + 1 }}} LiquidHaskell runs a transformation from the {{{CoreBind}}} for {{{gt}}} to its internal representation of decidable logic. Since Core plugins are run after "dead" code is removed at the end of desugaring, and since {{{gt}}} is not exported, the {{{CoreBind}}} for {{{gt}}} would not reach the {{{CoreBinds}}} LH receives as a Core plugin. The solution for this is to be able to mark names with {{{keepAlive}}} from Template Haskell. Proposed specification: {{{ keepAlive :: Name -> Q () }}} where {{{Name}}} is a Template Haskell {{{Name}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10823> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10746: No non-exhaustive pattern match warning given for empty case analysis
by GHC 02 Feb '17

02 Feb '17

#10746: No non-exhaustive pattern match warning given for empty case analysis -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would expect GHC to warn of a non-exhaustive pattern match at compile- time when faced with this, {{{#!hs {-# LANGUAGE EmptyCase #-} module Test where test :: Bool -> Int test a = case a of }}} Yet it happily accepts this without complaint. If one attempts to evaluate, e.g., `test True` the expected "Non-exhaustive patterns in case" error is thrown at runtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #10052: Panic (something to do with floatExpr?)
by GHC 31 Jan '17

31 Jan '17

#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Loading {{{ main = let (x :: String) = "hello" in putStrLn x }}} using a very simple driver for the GHC API (see T145.hs) causes a ghc panic: {{{ [1 of 1] Compiling Main ( T145-input.hs, interpreted ) T145: T145: panic! (the 'impossible' happened) (GHC version 7.10.0.20150128 for x86_64-apple-darwin): floatExpr tick <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This panic is arising in our test case for #8333, so it may be related to that bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #11444: 8.0 rc1 panics in applyTypeToArgs
by GHC 31 Jan '17

31 Jan '17

#11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- To reproduce, clone https://github.com/rrnewton/haskell-lockfree and switch to ghc-8.0 branch. Then run {{{cabal install atomic-primops/}}} (note the trailing slash, we don't want to install it from Hackage). It should fail with a message like this: {{{ ➜ haskell-lockfree git:(ghc-8.0) ✗ cabal install atomic-primops/ Warning: The package list for 'hackage.haskell.org' is 25.1 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Notice: installing into a sandbox located at /home/omer/haskell/haskell-lockfree/.cabal-sandbox Configuring primitive-0.6.1.0... Building primitive-0.6.1.0... Warning: /tmp/pkgConf-primitive-0.6.110252023621350490027.0: Unrecognized field abi on line 21 Installed primitive-0.6.1.0 Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Failed to install atomic-primops-0.8.0.2 Build log ( /home/omer/haskell/haskell-lockfree/.cabal-sandbox/logs /atomic-primops-0.8.0.2.log ): [1 of 1] Compiling Main ( atomic-primops/dist/dist-sandbox- ad71ba7e/setup/setup.hs, atomic-primops/dist/dist-sandbox- ad71ba7e/setup/Main.o ) Linking atomic-primops/dist/dist-sandbox-ad71ba7e/setup/setup ... Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Preprocessing library atomic-primops-0.8.0.2... [1 of 3] Compiling Data.Atomics.Internal ( Data/Atomics/Internal.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Internal.o ) Data/Atomics/Internal.hs:69:20: warning: Defined but not used: data constructor ‘Ticket’ [2 of 3] Compiling Data.Atomics.Counter ( Data/Atomics/Counter.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Counter.o ) [3 of 3] Compiling Data.Atomics ( Data/Atomics.hs, dist/dist-sandbox- ad71ba7e/build/Data/Atomics.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160111 for x86_64-unknown-linux): applyTypeToArgs Expression: readMutVar# eta_s4sC st_s4sD Type: forall d_15 a_12. MutVar# d_15 a_12 -> State# d_15 -> (# State# d_15, a_12 #) Args: [eta_s4sC, st_s4sD] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: atomic-primops-0.8.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11046: lookupTypeName does not support type operators
by GHC 30 Jan '17

30 Jan '17

#11046: lookupTypeName does not support type operators -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 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: -------------------------------------+------------------------------------- The following non-working code (minus a missing import) was [http://stackoverflow.com/questions/33465109/template-haskell-how-to- lookup-type-operator-name posted on stackoverflow]: `IssueTH.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module IssueTH where import Language.Haskell.TH f :: Q [Dec] f = do Just n <- lookupTypeName "GHC.TypeLits.*" return [] }}} `Issue.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Issue where import IssueTH import GHC.TypeLits $f }}} `ghc Issue.hs` fails with message: `Pattern match failure in do expression at IssueTH.hs:7:5-10` This gives no error if `*` is replaced by an alphanumeric type like `Nat`. Similar tests seem to fail whenever attempting to look up a type operator with `lookupTypeName`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility
by GHC 29 Jan '17

29 Jan '17

#10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A module loaded by a plugin poisons the module cache, so we never load an orphan RULE or instance even if we legitimately should do so. The way to test this is a bit convoluted, but it goes something like this: plugins07.hs {{{ module Main where import Plugins07a import RuleDefiningPlugin {-# NOINLINE x #-} x = "foo" main = putStrLn (show x) }}} Plugins07a.hs {{{ --{-# OPTIONS_GHC -fplugin RuleDefiningPlugin #-} module Plugins07a where }}} RuleDefiningPlugin.hs, in ANOTHER PACKAGE (otherwise, EPT rules don't apply) {{{ module RuleDefiningPlugin where import GhcPlugins {-# RULES "unsound" forall x. show x = "SHOWED" #-} plugin :: Plugin plugin = defaultPlugin }}} I'll commit the full test. Here's what happens: * Building `Plugins07a` results in `loadPluginInterface` on `RuleDefiningPlugin`. We load the `ModIface` but only add its types to the environment because of the "Care with plugin imports" special case. * Building `plugins07.hs` results in a normal source level import for `RuleDefiningPlugin`, but `ModIface` is already in the cache so we don't load anything. RULE is not loaded, disaster! Admittedly, actually triggering this bug requires a convoluted chain of events. But really this problem arose because the "Care with plugin imports" fix is just completely nonsense. Here's what we should do: * We should apply the same fix from #2182 on orphan instances to orphan rules too. This way, we can safely load RULEs into the EPS without accidentally bringing them into scope when they shouldn't be. * Loading an interface should unconditionally suck in the instances and rules. The result is more correct and simpler, so it seems worth fixing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9351: add ability to version symbols .c for packages with C code
by GHC 26 Jan '17

26 Jan '17

#9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Let's consider an example: We have a haskell package with some C code imported in haskell: {{{ // a.h file int get_something(void); // a.c file #include "a.h" int get_something(void) { return 42; } // M.hs file module M where foreign import ccall "a.h get_something" :: IO Int }}} The problem here is we can't mix that package with other packages having global 'get_something' symbol. Sometimes it happens when a package copies part of implementation from another package with .c bits under different haskell namespace. Haskell parts would coexist freely, but not C symbols. Would be great if ghc would export some unique package identifier in a way C code could attach it to all exported symbols making linking possible. Something like that: {{{ // a.h file #include "HsFFI.h" /* #define FOR_HASKELL(__sym) package_id_##__sym */ int FOR_HASKELL(get_something)(void); // a.c file #include "a.h" int FOR_HASKELL(get_something)(void) { return 42; } // M.hs file module M where foreign import ccall-for-haskell "a.h get_something" :: IO Int }}} That way we explicitly mark symbol as inaccessible to external plain C code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5