October 2015 - ghc-tickets

[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

[GHC] #8176: Language extensions not registered
by GHC 20 Feb '16

20 Feb '16

#8176: Language extensions not registered --------------------------------+------------------------------------------ Reporter: duncan | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: tests/driver/T4437.hs Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ tests/driver/T4437.hs does not seem to be being used properly. That test is there to make sure that ghc developers do not forget to register their new extensions with Cabal. But it looks like it's just being silenced and they are being forgotten again. Recall, the protocol is that all Haskell implementations can register their extensions in the central location (which is Language.Haskell.Extensions in the Cabal package) when they are happy that they are ready for public consumption. This matters to users because extensions that are not ready for public consumption (ie not registered) cannot be used in packages uploaded to hackage. Currently `tests/driver/T4437.hs` contains: {{{ expectedGhcOnlyExtensions = [ "AllowAmbiguousTypes", "RelaxedLayout", "AlternativeLayoutRule", "AlternativeLayoutRuleTransitional", "ExplicitNamespaces", "TypeHoles", "OverloadedLists", "EmptyCase", "AutoDeriveTypeable", "NegativeLiterals", "NullaryTypeClasses"] }}} This looks like a much bigger list than it should be. Surely not all of these extensions are private to ghc or are still under development and not to be used? But if they are listed here, then the test doesn't complain about them. And the whole point of this test is to stop ghc devs from forgetting to register them. I think we need to change the test so that we distinguish between extensions that are really not ready, and ones that are on-track to be public. It should be a release blocker for the "on-track to be public" ones to still not be registered. The test should have comments giving this guidance for ghc contributors. I'm not quite sure how we adjust the test to make that happen (ie different behaviour for RC-build vs normal hacking validate). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10196: Regression regarding Unicode subscript characters in identifiers
by GHC 19 Feb '16

19 Feb '16

#10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #5108 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As reported by both hvr as user Yongqian Li: The Unicode7 update in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1: For instance, GHCi 7.8.4 accepts let xᵦ = 1 let xᵤ = 1 let xᵩ = 1 let xᵢ = 1 let xᵪ = 1 let xᵣ = 1 let xₙ = 1 whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept *all* latin subscript letters either). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #9993: PostfixOperators doesn't work for types
by GHC 19 Feb '16

19 Feb '16

#9993: PostfixOperators doesn't work for types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `PostfixOperators` is a useful extension on the value level that defines `(x OP)` to mean `((OP) x)` for an infix operator `OP`, rather than `(\y -> (OP) x y)`. This could be even more useful on the type level, where lambdas are unavailable (so sections don't exist at all) but postfix operators could still exist. This is already a common pseudocode idiom in some cases, e.g. `(r ->)` instead of `((->) r)`. Is there a particular syntactic reason to disallow it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9518: Improve error message for unacceptable role annotations
by GHC 19 Feb '16

19 Feb '16

#9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | 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: -------------------------------------+------------------------------------- It would be nice if this message: {{{ Role mismatch on variable a: Annotation says representational but role nominal is required while checking a role annotation for `Point' }}} Could be extended to say where the requirement arises. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8981: ghc-pkg complains about missing haddock interface files
by GHC 19 Feb '16

19 Feb '16

#8981: ghc-pkg complains about missing haddock interface files --------------------------+------------------------------------------------ Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.8.2 Priority: normal | Version: 7.8.1 Component: | Operating System: MacOS X Compiler | Type of failure: Incorrect result at runtime Keywords: ghc- | Test Case: pkg | Blocking: Architecture: x86_64 | (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ As Conal reported on the mailing list[1], `ghc-pkg check` on Mavericks allegedly returns: {{{ bash-3.2$ ghc-pkg check Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory }}} It's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not. Marking for 7.8.2. I'm looking into this soon. [1]http://www.haskell.org/pipermail/glasgow-haskell- users/2014-April/024846.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package
by GHC 18 Feb '16

18 Feb '16

#9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | 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: -------------------------------------+------------------------------------- Suppose I have packages A-1.0, A-1.1, and B-1.0 built against A-1.0, and A (both versions) defines a type T which B defines to be an instance of some class C. If I load A-1.1 and B-1.0 into ghci and try to use the C T instance I will get a "No instance for C T" error, because T refers to A-1.1:T and B only defines an instance for A-1.0:T. However, if I don't realize this is what's going on, the error will be quite confusing as B appears to define an instance C T. Or, A could define the class C, rather than the type T, with the same result. This is quite common nowadays because there is a newer version of transformers (0.4.1.0) than the one which ships with GHC (0.3.0.0) and it's easy to end up installing mtl or lens against 0.3.0.0, and then some other package which pulls in 0.4.1.0. It would be nice to give a hint about what is going on, like {{{ No instance for (MonadIO X) arising from a use of ‘liftIO’ In the expression: ... ... Note: there is an instance transformers-0.3.0.0:MonadIO X }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8