July 2017 - ghc-tickets

[GHC] #11477: Remove -Wamp
by GHC 17 Nov '18

17 Nov '18

#11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This warning is intended as a temporary measure to aid the Applicative- Monad Proposal transition. It should be eventually removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10675: GHC does not check the functional dependency consistency condition correctly
by GHC 16 Nov '18

16 Nov '18

#10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances, ScopedTypeVariables #-} class C a b | a -> b where op :: a -> b instance C [x] [x] instance {-# OVERLAPS #-} C x y => C [x] [Maybe y] f x = op [x] }}} Should these two instance declarations be accepted? They are simply ''inconsistent'' in the sense of Definition 6 of the [http://research.microsoft.com/en-us/um/people/simonpj/papers/fd- chr/jfp06.pdf FDs through CHRs paper]. Sadly GHC does not currently reject these as inconsistent. As a result it'll use ''both'' instance for improvement. In the definition of `f` for example we get {{{ C [alpha] beta }}} where `x:alpha` and the result type of `f` is `beta`. By using both instances for improvement we get {{{ C [Maybe gamma] [Maybe gamma] }}} Is that what we want? The two instances don't ''contradict'' each other, but neither do they agree as all published work on FDs says they should! Examples in the testsuite that exploit this loophole are {{{ ghci/scripts ghci047 polykinds T9106 typecheck/should_compile FD4 typecheck/should_compile T7875 }}} I'm not sure what the right thing here is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr`
by GHC 15 Nov '18

15 Nov '18

#10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- An `HsExpr` should look exactly as a user wrote some Haskell code. Its pretty printer should therefore be quite dumb. Just print out the code! But a few places in GHC create `HsExpr`s and aren't scrupulous with regard to adding `HsPar` nodes where source syntax would need them. Thus, well- meaning souls have added `pprParendExpr` calls to the `HsExpr` pretty- printer to try to cover these cases. Simon and I [https://phabricator.haskell.org/D1219#34199 think] that we should remove all recursive uses of `pprParendExpr` from the `HsExpr` pretty-printer and instead add the `HsPar`s where necessary. It was recently reported that the following test cases break when simply removing `pprParendExpr`: {{{ Unexpected failures: deriving/should_fail T4846 [stderr mismatch] (normal) generics GenDerivOutput [stderr mismatch] (normal) generics GenDerivOutput1_0 [stderr mismatch] (normal) generics GenDerivOutput1_1 [stderr mismatch] (normal) ghci/scripts T10248 [bad stderr] (ghci) indexed-types/should_compile PushedInAsGivens [stderr mismatch] (normal) safeHaskell/safeLanguage SafeLang10 [stderr mismatch] (normal) safeHaskell/safeLanguage SafeLang17 [stderr mismatch] (normal) typecheck/should_fail T8603 [stderr mismatch] (normal) typecheck/should_fail tcfail177 [stderr mismatch] (normal) }}} See also considerable commentary on Phab:D1114. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13114: UniqSet definition seems shady
by GHC 13 Nov '18

13 Nov '18

#13114: UniqSet definition seems shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Currently, {{{#!hs type UniqSet a = UniqFM a }}} The key invariant of `UniqSet` is expressed in the somewhat-poorly-named `Note [Unsound mapUniqSet]`, and not enforced by the types. It seems likely that the clean thing is {{{#!hs newtype UniqSet a = US (UniqFM a) }}} Unfortunately there's an awful lot of code using `UniqSet` and assuming it's the same as `UniqFM`. To make this work, we'd need to expand the `UniqSet` API somewhat and figure out what to do at use sites using it interchangeably with `UniqFM`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s
by GHC 11 Nov '18

11 Nov '18

#11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- Haskell2010 states: > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`. Consider the following two modules: {{{#!hs -- module Main (main) where import Main2 (main) }}} {{{#!hs module Main2 (main) where main :: IO () main = return () }}} A non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with {{{ $ ghci Main.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help unknown option: 'c' [1 of 2] Compiling Main2 ( Main2.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Main.hs:1:1: The IO action ‘main’ is not exported by module ‘Main’ Failed, modules loaded: Main2. }}} For GHCi we need to uncomment the explicit `module Main (main) where` line to make it work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9692: Template Haskell reification for Data Families is buggy?
by GHC 08 Nov '18

08 Nov '18

#9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: TemplateHaskell | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have found an example where I think that the TH reification for data/newtype families is incorrect, in that if forgets non-instantiated type variables in instance declarations. For the attached example, it will infer the Info: {{{#!hs FamilyI (FamilyD DataFam TyFamReifyDefs.F [PlainTV a_1627399879,PlainTV b_1627399880] (Just StarT)) [DataInstD [] TyFamReifyDefs.F [ConT GHC.Types.Int] [NormalC TyFamReifyDefs.FInt [(NotStrict,VarT x_1627399881)]] []] }}} Note how the variable x is not declared in the body of the DataInstD. Since it does not need to have the same name as the family-declared variable, substituing is non-trivial this way... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b)
by GHC 08 Nov '18

08 Nov '18

#11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 7.8.3 (other) | Keywords: array | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Array` has `Eq`, `Ord`, `Show` and `Read` instances but `UArray` only has `Eq`, `Ord` and `Show`. Add the missing `Read` instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13933: Support Typeable instances for types with coercions
by GHC 07 Nov '18

07 Nov '18

#13933: Support Typeable instances for types with coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: TypeInType, | Operating System: Unknown/Multiple Typeable | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs {-# LANGUAGE GADTs, TypeApplications, TypeInType #-} module Bug where import Type.Reflection data G a where MkG :: a ~ Bool => G a rep = typeRep @MkG }}} I get {{{ Bug.hs:10:7: error: • No instance for (Typeable <>) arising from a use of ‘typeRep’ • In the expression: typeRep @MkG In an equation for ‘rep’: rep = typeRep @MkG | 10 | rep = typeRep @MkG | }}} First off, the error message is confusing, mentioning the mysterious `<>`. But more importantly, it would be nice if the `Typeable` mechanism supported coercions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11008: GND with Type Families
by GHC 07 Nov '18

07 Nov '18

#11008: GND with Type Families -------------------------------------+------------------------------------- Reporter: crockeea | 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: -------------------------------------+------------------------------------- In the following code: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances #-} class C r type family F r newtype Foo r = Foo r instance (C (F r), Eq r) => Eq (Foo r) newtype Bar r = Bar (Foo r) deriving (Eq) }}} GHC produces the error {{{ No instance for (C (F r)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq (Bar r)) }}} If I enable `StandaloneDeriving`, I am able to derive the instance: `deriving instance (Eq (Foo r)) => Eq (Bar r)` [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.ht… #newtype-deriving The docs] indicate that this is exactly the instance that should be generated by GND for `newtype T v1..vn = MkT (t vk+1..vn) deriving (C t1..tj)`, where my code uses the following parameters: {{{ T = Bar v1 = r n = 1 MkT = Bar t = Foo r k= 1 C = Eq j = 0 }}} and all of the conditions enumerated in the docs seem to be met. Furthermore, `Bar` seems to fit squarely into the format of `data T1` in section 7.5.1 of the same documentation, which indicates it should not need `StandaloneDeriving`. It seems that the type family constraint on the `Eq` instance for `Foo` is causing the problem, but it's not clear why I'm forced to write a standalone instance that is identical to the one that should be generated by GND. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12620: Allow the user to prevent floating and CSE
by GHC 07 Nov '18

07 Nov '18

#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- This is a write-up of a rough idea that Andres Löw and me had at ICFP 2016 in order to address some Real World problems Andres noticed and that are currently hard to avoid. The goal is to give the user more control about expressions that the compiler would like to float out (or CSE), but the programmer knows better. Example (assume no list fusion exists): {{{ enum xs = zip [1..] xs }}} This leads to a horrible space leak, as GHC will float out `[1..]` to the top. Our idea is to have a magic function `nofloat :: a -> a` (magic in the same sense as `inline` and `lazy`) that the programmer would use here: {{{ enum xs = zip (nofloat [1..]) xs }}} With these effects: * Sub expressions are not floated out of a `nofloat`. * An expression of the form `nofloat e` would not be floated beyond the innermost enclosing lambda. * Two expressions of the form `nofloat e` would not be commoned up by CSE. This way, unwanted sharing is prevented. In contrast to a hypothetical `veryCheap` function, it does ''not'' mean that the compiler should float it into lambda (no unwanted duplication either). Two open questions (among many others, I am sure:) * Likely, rule matching should look through `nofloat`. At least in this example (and similar ones like `map (nofloat [1..])`, the rules in question will avoid the spaceleaks). * Possibly, nothing should be floated (inlined) ''into'' a `nofloat`. Rationale: Assume the library is changed so that {{{ [n..] = nofloat (realEnumFrom n) {-# INLINE [n..] #-} }}} Then `zip [fib 1000..]` would be rewritten by the inliner to `zip (let x = fib 1000 in (nofloat [x..]))`. Moving the `fib 1000` into the `nofloat` would change the behaviour in a possibly surprising way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12620> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34