December 2015 - ghc-tickets

[GHC] #9043: Add missing type class instances for data types in GHC.Generics
by GHC 27 Feb '16

27 Feb '16

#9043: Add missing type class instances for data types in GHC.Generics ------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC.Generics offers a bunch of data types which have valid instances of various type classes in base, such as Functor. There's no good reason not to have these instances, so they should be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #10316: Move Typeable type-rep generation from use site to definition site
by GHC 27 Feb '16

27 Feb '16

#10316: Move Typeable type-rep generation from use site to definition site -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This ticket is a continuation of #9858. The interim solution for 7.10 was to generate `Typeable` data structures on the fly, as needed in client modules. This ticket is about moving the generation of the runtime representation of type constructors to their definition sites. (#9858 already has too much going on in it, so I started a fresh ticket for this refactoring.) The branch is `wip/T9858-typeable-spj`. In favour of (A) code at use site (as in 7.10): * Pay as you go. No code at all is generated unless you use `Typeable` In favour of (B) code at definition site: * More sharing. We make a `TyCon` (see `Data.Typeable.Internal`) for `T` (say) just once, in the module that defines `T`. * We may ultimately want the `TyCon` for `T` to include its source location, and perhaps more besides. If it is defined in `T` it becomes easier to do that. General observation: (B) is like `Typeable` was before, when it was an ordinary class. The difference now is that all types are `Typeable`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8710: Overlapping patterns warning misplaced
by GHC 27 Feb '16

27 Feb '16

#8710: Overlapping patterns warning misplaced -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: Priority: low | Version: 7.7 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider {{{ {-# OPTIONS_GHC -fwarn-overlapping-patterns #-} len [] = 0 len (_:t) = 1 + len t len _ = error "urk" }}} GHC reports the problem with this definition at the first line of it. I think it would be more helpful to have it at the last line, which is the pattern that will never match. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set
by GHC 27 Feb '16

27 Feb '16

#9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- to reproduce put {{{ main= putStrLn "hello world" }}} in hello.hs and then invoke `ghc hello.hs -O2 -v3 -fforce-recomp -ddump-llvm` then at some point you'll see something like {{{ *** LLVM Optimiser: opt-3.4 /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_2.ll -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_4.bc -O2 '--enable-tbaa=true' *** LLVM Compiler: llc-3.4 -O2 '-relocation-model=pic' /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_4.bc -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc88460_0/ghc88460_5.lm_s '--enable-tbaa=true' '-mattr=+sse2' *** LLVM Mangler: }}} in the output -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linke
by GHC 27 Feb '16

27 Feb '16

#11123: Arm: checkProddableBlock: invalid fixup in runtime linke --------------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Just started getting this in the last week or two, but only just now got a chance to investigate more fully. Any use of GHCi or TH will result in an error like: {{{ ghc-stage2: internal error: checkProddableBlock: invalid fixup in runtime linker: 0x41380050 (GHC version 7.11.20151122 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} As a consequence, there are now over 500 failing tests on Arm. I thought this may have been a consequence of all the recent work on `rts/Linker.c` so I checked out git commit 20e30d5f3d932d63933 (the one just before the dreaded commit 04e8366608fee4f which seemed to kick off a bunch of heavy rework in this file) but that revision causes another, even more mysterious linking failure. From what I have seen, this only affects 32 bit Arm. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11009: Errors reading stdin on Windows
by GHC 26 Feb '16

26 Feb '16

#11009: Errors reading stdin on Windows -------------------------------------+------------------------------------- Reporter: ncreep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I'm running GHC 7.10.2 on Windows 7 x64. Given this code that reads bytes of `stdin`: {{{#!hs import Foreign.C import Foreign import System.Posix.Internals import qualified GHC.IO.FD as FD readStdin bytes = allocaBytes bytes $ \p -> throwErrnoIfMinus1 "" $ c_safe_read (FD.fdFD FD.stdin) p (fromIntegral bytes) }}} Running {{{#!hs readStdin (32 * 1024) }}} Throws the following {{{ *** Exception: resource exhausted (Not enough space) }}} Taking less bytes, e.g. `readStdin (30 * 1024)`, runs as expected. This code is motivated by [[https://github.com/haskell/bytestring/issues/35|this]] issue in the `bytestring` library. This is essentially a minimization of the error case [[https://github.com/haskell/bytestring/issues/35#issuecomment-148954406|here]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10217: Provide link to GPG signature on download page.
by GHC 25 Feb '16

25 Feb '16

#10217: Provide link to GPG signature on download page. -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple Documentation | Type of failure: Documentation Keywords: GPG, | bug signature | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As now, in the section "Binary packages" of GHC download page, you can read: > SHA-256 hashes for all the binary distributions are available here. with a link to the hashes' file. It would be great to provide a link to the signature of this file too, i.e.: > SHA-256 hashes for all the binary distributions are available here[link] (GPG signature available here[link], signed with key <keyID>). Hashes and Signatures are advertised in the mailing list release post, but I guess it would be nice for clarity's sake having them on the download page too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10336: Support qualified self {-# SOURCE #-} import
by GHC 25 Feb '16

25 Feb '16

#10336: Support qualified self {-# SOURCE #-} import -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: ⊥ Priority: lowest | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: 7672 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The source import in this module is a no-op and has no legitimate use: {{{ module A where import {-# SOURCE #-} A }}} It's also tricky to support properly, see #10182. So we will disable it. However, there is one mode of use which cannot be legitimately done in normal Haskell: a qualified source import: {{{ module A where import {-# SOURCE #-} qualified A as MyA }}} The intended semantics is that the boot entities defined in A.hs-boot are available under the qualification MyA. Fixing #7672 would get us most of the way here, but there is one more step to avoid regressing #10182. So this just seems not worth fixing, unless someone really wants it. (Note: regular self imports could also be supported this way, but it would be even more complicated to do, since we don't even know what OccNames to add provenances for.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10398: Support consecutive named Haddock comments
by GHC 25 Feb '16

25 Feb '16

#10398: Support consecutive named Haddock comments -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- (I don't sufficiently understand the manner in which this arises from a GHC issue, but reliable sources inform me that it does.) This haddock issue, https://github.com/haskell/haddock/issues/392, apparently is related to the manner in which GHC parses comments. The way it manifests is that {{{#!hs module Foo ( -- $chunk1 -- $chunk2 foo, -- $chunk3 bar ) where {- $chunk1 This is chunk 1. -} {- $chunk2 This is chunk 2. -} {- $chunk3 This is chunk 3. -} foo = 3 bar = 7 }}} The resulting haddock documentation will include chunks 1 and 3 but not 2. See the linked ticket for a discussion by Mateusz Kowalczyk explaining how this relates to GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10484: hPutBuf crashes when trying to write a large string to stdout (resource exhausted)
by GHC 25 Feb '16

25 Feb '16

#10484: hPutBuf crashes when trying to write a large string to stdout (resource exhausted) -------------------------------------+------------------------------------- Reporter: bayloff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Operating System: Windows Keywords: | Type of failure: Runtime crash Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program crashes when I try to write a byte string larger than 61kb to stdout: {{{#!hs import qualified Data.ByteString.Char8 as BS main = BS.putStrLn $ BS.replicate (62 * 1024) 'x' }}} When I run the above, I get the following runtime error: {{{ <stdout>: hPutBuf: resource exhausted (Not enough space) }}} GHC versions tested: 7.6.3 and 7.8.3 (both 32 and 64 bit) OS: Windows 7 and Windows Server 20008R2 The issue is not reproducible with the Linux version of GHC. It is also not reproducible if I use the Lazy variant of the byte strings. Note: The Linux version of the program was tested with GHC 7.6.3 because this is the one I have on my Ubuntu machine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2