January 2016 - 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] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base
by GHC 25 Feb '16

25 Feb '16

#11349: [TypeApplications] Create Proxy-free alternatives of functions in base ----------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Keywords: TypeApplications | Operating System: Other Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Now that we have [https://phabricator.haskell.org/D1138 TypeApplications] how about we create a Proxy-free version of functions in base that currently require it: {{{#!hs tr :: forall a. Typeable a => TypeRep tr = typeRep @Proxy @a Proxy symbol :: forall s. KnownSymbol s => String symbol = symbolVal @s Proxy nat :: forall n. KnownNat n => Integer nat = natVal @n Proxy }}} While we're at it let's use [https://hackage.haskell.org/package/base/docs /Numeric-Natural.html Natural] as the value-level representation of Nat, avoiding `Maybe` in `someNatVal :: Integer -> Maybe SomeNat`: {{{#!hs nat :: forall n. KnownNat n => Natural nat = natVal @n Proxy someNatVal :: Natural -> SomeNat someNatVal = ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #11106: Optimizer changes behavior in 7.10.3
by GHC 20 Feb '16

20 Feb '16

#11106: Optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The repository at https://github.com/ddssff/ghcbug contains a four module package that works when compiled with -O2, but fails when compiled with -O2. The cabal file builds working and failing executable. One of the modules has OPTIONS_GHC -O0 in the header, so the bug is related to mixing modules with different optimization levels. Other than that, I have little idea what is going on. The bug was present in 7.10,2, and is definitely still present in 7.10.3-rc1. I doubt it has been fixed since then. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[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] #11191: provide `make uninstall`
by GHC 19 Feb '16

19 Feb '16

#11191: provide `make uninstall` -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: installation | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As now there is no `make uninstall` for GHC. Even though most of the times this is not strictly needed, there are cases where this would be useful (a system with not much disk space available). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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