June 2016 - ghc-tickets

[GHC] #9247: Document -XDatatypeContexts in flag reference
by GHC 03 Jun '18

03 Jun '18

#9247: Document -XDatatypeContexts in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- It may be a deprecated feature, but it still exists and should be listed. I can do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness?
by GHC 03 Jun '18

03 Jun '18

#11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10.2 reports inaccessible branches as a type error, and I think this is really a bug. First, the implicit thinking seems to be "why would a user want to write inaccessible cases, they'd be crazy!". But that only applies to human-written code. Program generators can have a great deal of trouble avoiding this error, unless they replicate the GHC type checker to predict the problem and prune branches. (That's why we are hitting this error and are stuck.) Second, it seems like this is a problem for type soundness. See the attached program where "step1" typechecks but "step2" does not. And yet, the operational semantics should allow step1 to reduce to step2. Indeed, in the "GADTs meet their match" paper it seems like the intent was to warn for these inaccessible cases, not error. For example, the paper contains the language: "If we warn that a right-hand side of a non-redundant clause is inaccessible," -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #9724: reexport IsList class from a trustworthy module
by GHC 31 May '18

31 May '18

#9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: -------------------------------------+------------------------------------- ==== Motivation GHC's Safe Haskell extension relies to a large extent on inferring safety of modules automatically. As a concrete example, [[http://hackage.haskell.org/package/data-default|data-default]] used to be inferred safe. This is no longer the case, because [[http://hackage.haskell.org/package/dlist-0.7.1|dlist-0.7.1]] added an {{{IsList}}} instance for difference lists. The only way to do that currently is to import the relevant parts of {{{GHC.Exts}}}, and that module is not safe. Of course the resulting non-safety of the {{{Data.DList}}} module can be fixed by adding a {{{TrustWorthy}}} pragma to the module and trusting the {{{dlist}}} package. But that is unsatisfactory, because there is nothing unsafe about providing an instance for the {{{IsList}}} class. This issue is bound to pop up in other packages as well. ==== Proposed Solution (this is one of many possibilities) Add a {{{GHC.Exts.Safe}}} module that is marked {{{TrustWorthy}}} and reexports the {{{IsList}}} class, and possibly other things from {{{GHC.Exts}}} that are safe to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9479: Report required constraints when reporting the type of a hole
by GHC 30 May '18

30 May '18

#9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: dominiquedevriese | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: holes | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For the following code {{{ module Test where test :: String test = show _h }}} GHC currently reports: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Applicable constraints: Show a0 Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9438: panic: loading archives not supported
by GHC 29 May '18

29 May '18

#9438: panic: loading archives not supported ----------------------------------+---------------------------------- Reporter: egl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------- Running {{{ ghci -L/opt/local/lib -latlas }}} eventually leads to {{{ Loading object (static archive) /opt/local/lib/libatlas.a ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This looks similar to 8164 and 4828, which are marked closed. Mac OSX 10.9.4 Xcode 5.1.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10843: Allow do blocks without dollar signs as arguments
by GHC 29 May '18

29 May '18

#10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would like the following to be valid Haskell code: {{{#!hs main = when True do putStrLn "Hello!" }}} Instead of requiring a dollar sign before the "do". This would parse as {{{#!hs main = when True (do putStrLn "Hello!") }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #9793: Some as-patterns could be accepted in pattern synonyms
by GHC 29 May '18

29 May '18

#9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: pattern synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | None/Unknown hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Currently all as-patterns are rejected in pattern synonym definitions, to avoid situations like {{{ pattern P x y <- x@(y:_) }}} since there's no valid reason to be able to then write something like {{{ f [True] False = ... }}} this would just lead to confusion. However, I think we could accept as-patterns where the body of the as- pattern doesn't contain any variable bindings that are accessible via the pattern synonym. In other words, this should be OK: {{{ pattern P x <- x@(y:_) }}} since it's exactly equivalent to {{{ pattern P x <- x@(_:_) }}} which I don't think is as confusing as the other example. I haven't really made up my mind yet if these should be bidirectional; but they certainly could be, by just ignoring the body of the as-pattern in the wrapper; so the following two would be equivalent: {{{ pattern P1 x = [x@(y:_)] pattern P2 x <- [x@(y:_)] where P2 x = [x] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations
by GHC 27 May '18

27 May '18

#9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In the resolution to #9200, as detailed [wiki:GhcKinds/KindInference#Apossiblevariation here], we identified an area for improvement. This improvement was not implemented in the fix for #9200. This ticket will track just this improvement. (In brief: we can do better dependency analysis on mutually recursive type/class declarations to allow more kinds to generalize earlier. This would lessen the burden on programmers to put in kind annotations. See the wiki page.) A solid but unfinished attempt is [https://github.com/goldfirere/ghc/tree /re-sort-non-cusk-decls here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10141: Kind inference regression in closed type families
by GHC 27 May '18

27 May '18

#10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Take the following definition: {{{ type family G (a :: k) where G Int = Bool G Bool = Int G a = a }}} It compiles in 7.8.3, but not in 7.10.1 RC2. This makes me sad. I will fix. (Found by Jan Stolarek.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11767: Add @since annotations for base instances
by GHC 26 May '18

26 May '18

#11767: Add @since annotations for base instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 7.10.3 Libraries | 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: -------------------------------------+------------------------------------- Up until now we haven't been adding `@since` annotations for instances that we add to `base` (see Phab:D2051 for the discussion that spurred this ticket). We should try to get better coverage here. Unfortunately, we currently have no way to place Haddock comments on derived instances, which limits our ability consistently add these annotations. We'll need to work out some mechanism for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16