November 2014 - ghc-tickets

[GHC] #8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals
by GHC 18 Apr '16

18 Apr '16

#8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals ----------------------------+---------------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals. (And I don't like either option, why leave out any characters in strings unnecessarily?) Examples from ghci 7.6.3 (also tested in lambdabot on irc): {{{ Prelude> "" -- Unicode char \8203, Format class. <interactive>:10:2: lexical error in string/character literal at character '\8203' Prelude> " " -- Unicode char \8202, Space class. "\8202" Prelude> "t\ \est" -- Unicode char \8202 in a string gap. <interactive>:14:4: lexical error in string/character literal at character '\8202' }}} My reading of http://www.haskell.org/onlinereport/haskell2010/haskellch2.html (section 2.2 and 2.6): * The report BNF token "graphic", which can be used in literals, includes indirectly many Unicode classes, but uniWhite is not one of them. Thus the only Unicode whitespace allowed to represent itself in literals is ASCII space. * Unicode formatting characters are not mentioned in the BNF that I can see, so are not allowed in literals. * String gaps are made out of the report BNF token whitespace, which ''does'' include uniWhite. Who wants what: || ||= GHC =||= Report =||= Me =|| || Format in string || No || No || Yes || || Space/uniWhite in string || Yes || No || Yes || || Space/uniWhite in string gap || No || Yes || Dunno || In short, GHC's behavior is buggy and/or annoying in two opposite ways: * It leaves out some Unicode characters as allowable in strings and character literals, presumably because the report says so. * It allows some characters the report says it ''shouldn't'', and refuses some characters the report says it ''should''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8468: ghc panic in deriving Generic1 on Array#
by GHC 07 Apr '16

07 Apr '16

#8468: ghc panic in deriving Generic1 on Array# -----------------------------------+--------------------------------------- Reporter: ghorn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Compiling the following code {{{ {-# Language DeriveGeneric, MagicHash #-} module Test where import GHC.Generics import GHC.Prim data Array a = Array (Array# a) newtype Vec a = MkVec {unVec :: Array a} deriving Generic1 }}} causes panic: {{{ [1 of 1] Compiling Test ( Test.hs, Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): No match in record selector tyConTyVars Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} some comments from IRC: <monoidal> with deriving Generic1 we get "Can't make a derived instance of `Generic1 Array': Array must not have unlifted or polymorphic arguments" - so it seems the check is not done recursively on used types <monoidal> * deriving Generic1 on Array -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8416: GHC.Generics needs more documentation
by GHC 07 Apr '16

07 Apr '16

#8416: GHC.Generics needs more documentation -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | 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: | -------------------------------------+------------------------------------- Recently I tried to used `GHC.Generics` "in anger" for the first time, to fix some code in hashable that wasn't originally written by me. After a while I just gave up (and the generics support in hashable is now somewhat broken). The documentation for `GHC.Generics` is too incomprehensible for mere mortals. In particular, I find the documentation for `M1` and `K1` not very helpful. The documentation needs examples, more in-depth explanations of what each of the data types/constructors is used for, and finally an explanation of the up to 4 type parameters! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8797: Generics instances for monoid and applicative newtypes
by GHC 07 Apr '16

07 Apr '16

#8797: Generics instances for monoid and applicative newtypes -------------------------------------------+------------------------------- Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Hi, Is there any particular reason why there aren't Generic instances for the newtypes under Data.Monoid and Control.Applicative (for example)? I've tried adding them to GHC/Generics.hs and base compiles without problems. Could this addition be considered? Best Regards, João -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8929: Deriving Generics broken
by GHC 07 Apr '16

07 Apr '16

#8929: Deriving Generics broken ----------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I load the following code into ghci: == {-# LANGUAGE DeriveGeneric #-} import GHC.Generics import Data.Binary data Foo = Foo deriving (Show, Generic) instance Binary Foo == Then I execute: (decode . encode $ Foo) :: Foo In 7.6.3 (stage 2 booted 7.6.3), I get an error. In 7.6.3 (stage 2 booted 7.6.2), the desired result "Foo" is shown. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8929> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9523: Typo in GHC Generics documentation
by GHC 07 Apr '16

07 Apr '16

#9523: Typo in GHC Generics documentation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Documentation | Version: 7.8.3 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: -------------------------------------+------------------------------------- In `GHC.Generics`: The types `S`, `C` and `R` are once again type-level proxies, just used to create several variants of `M1`. The `R`, it seems, is supposed to be a `D`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9527: Add Generic instances for Language.Haskell.TH
by GHC 07 Apr '16

07 Apr '16

#9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: 9526 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Template Haskell has a number of huge data types that would be much easier to work with if they had `Generic` instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9563: Support for deriving Generic1 for data families
by GHC 07 Apr '16

07 Apr '16

#9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code: {{{#!hs import GHC.Generics data family F typ :: * -> * data A data instance F A a = AData a deriving Generic1 }}} produces an error when run with ghc 7.8.2 or 7.8.3: {{{ Couldn't match type ‘Rep1 (F A)’ with ‘M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1))’ The type variables ‘t0’, ‘t1’, ‘t2’, ‘t3’, ‘t4’, ‘t5’ are ambiguous Expected type: Rep1 (F A) a Actual type: M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1)) a In the pattern: M1 (M1 (M1 g1)) In an equation for ‘to1’: to1 (M1 (M1 (M1 g1))) = AData (unPar1 g1) In the instance declaration for ‘Generic1 (F A)’ }}} whereas ghc 7.6.3 simply refuses to go ahead with the message: {{{ generic1.hs:14:40: Derived instance `Generic1 (F A)' requires illegal partial application of data type family F In the data instance declaration for `F' }}} Either a check has gone missing in 7.8.x, or a bug has crept up in the Generic1 support. I have gone through past tickets and https://ghc.haskell.org/trac/ghc/ticket/5936 suggests that it is the latter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X
by GHC 06 Apr '16

06 Apr '16

#8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X ------------------------------------+--------------------------------- Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- According to the OS X man page for sysctl(https://developer.apple.com/library/mac/documentation/Darwin/Referen…, HW_NCPU used by the current implementation of getNumberOfProcessors() is deprecated. Instead, Mac OS X provides the following 4 options: * hw.physicalcpu: The number of physical processors available in the current power management mode. * hw.physicalcpu_max: The maximum number of physical processors that could be available this boot. * hw.logicalcpu: The number of logical processors available in the current power management mode. * hw.logicalcpu_max: The maximum number of logical processors that could be available this boot. I am not sure which one fits best to GHC runtime. Any idea? sysconf implementation of getNumberOfProcessors() seems to prefer _SC_NPROCESSORS_ONLN to _SC_NPROCESSORS_CONF when both are defined. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8731: long compilation time for module with large data type and partial record selectors
by GHC 30 Mar '16

30 Mar '16

#8731: long compilation time for module with large data type and partial record selectors -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc1 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- in both ghc 7.6 and 7.8rc, the Constants module in LLVM-General-Pure (and a few other similar modules) have surprisingly long (and noticable!) compilation times. This seems to related to how GHC handles a many constructor data type with overlapping field names. the time is nearly the same for building a static module with O1 and O2 {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O2 1 ↵ [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O2 7.52s user 0.23s system 99% cpu 7.755 total }}} {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O1 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O1 6.62s user 0.20s system 100% cpu 6.768 total }}} heck even with -O0 its slow (though not terrible) {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O0 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O0 2.76s user 0.14s system 101% cpu 2.873 total }}} Seems like there might something wrong in how we handle data types like this, the complexity need not -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11