June 2016 - ghc-tickets

[GHC] #10221: LLVM does not work on OSX
by GHC 01 Nov '16

01 Nov '16

#10221: LLVM does not work on OSX -------------------------------------------+---------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- I can't seem to be able to use the LLVM backend on OSX. I get the error: {{{ error: unknown directive .macosx_version_min 10, 0 ^ <no location info>: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) <no location info>: ghc: phase `Clang (Assembler)' failed (exitcode = 1) }}} This is on GHC 7.10.1 {{{ % clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix yongqli@auxiliary ~/secrets/projects/stocvol % opt --version LLVM (http://llvm.org/) LLVM version 3.5.1 Optimized build with assertions. Built Jan 15 2015 (18:24:46). Default target: x86_64-apple-darwin14.1.0 Host CPU: core-avx2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9858: Typeable instance for datatype and its promoted constructor is the same
by GHC 26 Oct '16

26 Oct '16

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A = A main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}} This returns `True`, but it should return `False`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 119

[GHC] #12174: Recursive use of type-in-type results in infinite loop
by GHC 24 Oct '16

24 Oct '16

#12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- Typechecking this module results in an infinite loop: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeInType #-} module X where data V a data T = forall (a :: S). MkT (V a) data S = forall (a :: T). MkS (V a) }}} There's a mutually recursive reference so it should be rejected but maybe the check is not happening early enough (or the existing check is only for self-reference.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12081: TypeInType Compile-time Panic
by GHC 24 Oct '16

24 Oct '16

#12081: TypeInType Compile-time Panic -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been playing around with GHC 8.0.1-rc4 release and got a panic from the following (stripped down) code: {{{#!hs {-# LANGUAGE TypeInType #-} data Nat = Z | S Nat class C (n :: Nat) where type T n :: Nat f :: (a :: T n) }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160421 for x86_64-apple-darwin): isInjectiveTyCon sees a TcTyCon T }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11339: Possible type-checker regression in GHC 8.0
by GHC 21 Oct '16

21 Oct '16

#11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- The following code (extracted from hackage:microlens) type-checks on GHC 7.10 but '''not''' on GHC 8.0/8.1: {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Failing where import Control.Applicative ( Const(Const, getConst) ) import Data.Functor.Identity ( Identity(Identity) ) type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t failing :: forall s t a b . Traversal s t a b -> Traversal s t a b -> Traversal s t a b failing left right afb s = case pins t of [] -> right afb s _ -> t afb where -- t :: (a -> f b) -> f t -- TYPECHECKS with GHC 7.10, but not with GHC 8.x: Bazaar { getBazaar = t } = left sell s -- FAILS TO TYPECHECK with GHC 7.10 and GHC 8.x: -- t = getBazaar (left sell s) sell :: a -> Bazaar a b b sell w = Bazaar ($ w) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] pins f = getConst (f (\ra -> Const [Identity ra])) newtype Bazaar a b t = Bazaar { getBazaar :: (forall f. Applicative f => (a -> f b) -> f t) } instance Functor (Bazaar a b) where fmap f (Bazaar k) = Bazaar (fmap f . k) instance Applicative (Bazaar a b) where pure a = Bazaar $ \_ -> pure a Bazaar mf <*> Bazaar ma = Bazaar $ \afb -> mf afb <*> ma afb }}} The following error is emitted on GHC 8.0: {{{ failing.hs:13:11: error: • Couldn't match type ‘f’ with ‘Const [Identity a]’ ‘f’ is a rigid type variable bound by the type signature for: failing :: forall (f :: * -> *). Applicative f => Traversal s t a b -> Traversal s t a b -> (a -> f b) -> s -> f t at failing.hs:11:1 Expected type: a -> Const [Identity a] b Actual type: a -> f b • In the first argument of ‘t’, namely ‘afb’ In the expression: t afb In a case alternative: _ -> t afb • Relevant bindings include t :: (a -> Const [Identity a] b) -> Const [Identity a] t (bound at failing.hs:18:26) sell :: a -> Bazaar a b b (bound at failing.hs:24:5) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] (bound at failing.hs:27:5) afb :: a -> f b (bound at failing.hs:11:20) right :: Traversal s t a b (bound at failing.hs:11:14) left :: Traversal s t a b (bound at failing.hs:11:9) failing :: Traversal s t a b -> Traversal s t a b -> Traversal s t a b (bound at failing.hs:11:1) }}} I don't understand why `Bazaar t = ...` vs `t = getBazaar ...` makes a difference in GHC 7.10 at all. So I'm not sure if this is a regression or actually something that got fixed in GHC 8.0... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb
by GHC 20 Oct '16

20 Oct '16

#12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb ----------------------------------------+--------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #11627 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Reproducible with 7.10.3, 8.0.1 and today's HEAD ( afa6e8309e8e7a069abcf7879791d53cdf22f00a). The test was added by @jme in #11627. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12140: Clarify Trac menus for new reporters
by GHC 19 Oct '16

19 Oct '16

#12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.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: -------------------------------------+------------------------------------- An officemate of mine rarely posts bugs here. He finds the interface to posting a bug confusing. I have to say I agree, if I consider the perspective of an infrequent reporter. (The reason he rarely posts bugs is that he rarely has bugs to post, not because of the confusing interface.) Specifically, there are many fields to fill out when posting a bug. Some of these are important to us (`Version` probably being the most). Some are better for developers to set (`Milestone`, `Test case`). Some are less important (`Operating System` for a bug in the type-checker). Some are essentially ignored (`Type of failure`, in my experience). Yet a new reporter doesn't know any of this and will diligently try to fill out them all. Can we label the fields as to importance somehow? Mark some as advanced/dev only? Make some available only after posting the ticket (`Test case`, `Differential`)? I don't suppose there are masses of people out there trying to post bugs and stymied by this problem, but I do think we can clean this up a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11214: Remove JavaScriptFFI from --supported-extensions list
by GHC 18 Oct '16

18 Oct '16

#11214: Remove JavaScriptFFI from --supported-extensions list -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- GHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker. Similar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaScriptFFI` is not supported. Cabal 1.24 can then use this information in dependency resolution. GHCJS would then just add this to the list by itself, since it has its own front end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12044: Remove sortWith in favor of sortOn
by GHC 17 Oct '16

17 Oct '16

#12044: Remove sortWith in favor of sortOn -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 2659 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is Data.List.sortOn that does the same as GHC.Exts.sortWith, and even seems to be more effective. GHC.Exts.sortWith should be deprecated or removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11108: Weak references related crash
by GHC 17 Oct '16

17 Oct '16

#11108: Weak references related crash ----------------------------------------+---------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs): Most frequently just Segmentation fault (with no stack trace) Occasionally this: {{{ bench: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} and more rarely this: {{{ bench: internal error: WEAK object entered! (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33