- ghc-tickets - Haskell.org

[GHC] #10748: Associated type families regression
by GHC 07 Aug '15

07 Aug '15

#10748: Associated type families regression -------------------------------------+------------------------------------- Reporter: slyfox | 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 Revisions: | -------------------------------------+------------------------------------- The original code snippet is taken from synthesizer-core-0.7.1 from hackage: http://code.haskell.org/synthesizer/core/src/Synthesizer/Causal/Class.hs Here is the minimal example: {{{#!hs {-# LANGUAGE TypeFamilies #-} module M where class ProcessOf (SignalOf process) ~ process => C process where type SignalOf process :: * -> * type ProcessOf (signal :: * -> *) :: * -> * -> * }}} {{{ $ ghc -c M.hs M.hs:4:1: The associated type ‘ProcessOf’ mentions none of the type or kind variables of the class ‘C process’ In the class declaration for ‘C’ }}} ghc-7.8.4 was able to compile this. Is it a known new restriction of ghc or a regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 07 Aug '15

07 Aug '15

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Oh hm, of course, purging that easily only works when the type family isn't imported from a module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10609: Make up instances
by GHC 07 Aug '15

07 Aug '15

#10609: Make up instances -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following instances are missing as of now. * Foldable ZipList * Traversable ZipList * Functor Complex * Foldable Complex * Traversable Complex * Applicative Complex * Monad Complex * Monoid a => Monoid (Identity a) Original discussion: https://mail.haskell.org/pipermail/libraries/2015-June/025886.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 07 Aug '15

07 Aug '15

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Since you said not to mind Safe Haskell, I also found a similar unsoundness that uses loading of modules instead. All the modules can be `Safe`, but GHCi itself cannot have the flag set. {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T1 where type family T a b }}} {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T2 where import T1 type instance T a b = a from :: a -> T a b from = id }}} {{{ {-# LANGUAGE Safe, TypeFamilies #-} module T3 where import T1 type instance T a b = b to :: T a b -> b to = id }}} Now in GHCi: {{{ Prelude> :l T2 T3 [1 of 3] Compiling T1 ( T1.hs, interpreted ) [2 of 3] Compiling T3 ( T3.hs, interpreted ) [3 of 3] Compiling T2 ( T2.hs, interpreted ) Ok, modules loaded: T2, T1, T3. *T2> :m +T3 *T2 T3> let uc = to . from *T2 T3> uc 'a' :: Int 97 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7919: Heap corruption (segfault) from large 'let' expression
by GHC 07 Aug '15

07 Aug '15

#7919: Heap corruption (segfault) from large 'let' expression -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: rts/T7919 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1113 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7919#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 07 Aug '15

07 Aug '15

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): I suspect the purging in (2) can already be achieved by just redeclaring the type family, after which new instances would refer to the new entity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7669: Empty case causes warning
by GHC 07 Aug '15

07 Aug '15

#7669: Empty case causes warning -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: duplicate | Keywords: EmptyCase Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | deSugar/should_compile/T7669 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The issue of no warnings being produced despite non-exhaustive pattern matches (described in comment:3) has been reported separately as #10746. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7669#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9953: Pattern synonyms don't work with GADTs
by GHC 06 Aug '15

06 Aug '15

#9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this variant of test `T8968-1`: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms #-} module ShouldCompile where data X :: * -> * where Y :: a -> X (Maybe a) pattern C :: a -> X (Maybe a) pattern C x = Y x foo :: X t -> t foo (C x) = Just x }}} * If we had `(Y x)` instead of `(C x)` in the LHS of `foo`, then this is an ordinary GADT program and typechecks fine. * If we omit the pattern signature, it typechecks fine, and `:info C` says {{{ pattern C :: t ~ Maybe a => a -> X t -- Defined in ‘ShouldCompile’ }}} * But as written, it fails with {{{ Foo.hs:11:6: Couldn't match type ‘t’ with ‘Maybe a0’ ‘t’ is a rigid type variable bound by the type signature for: foo :: X t -> t at Foo.hs:10:8 Expected type: X t Actual type: X (Maybe a0) Relevant bindings include foo :: X t -> t (bound at Foo.hs:11:1) In the pattern: C x In an equation for ‘foo’: foo (C x) = Just x }}} Moreover, `:info C` says {{{ pattern C :: a -> X (Maybe a) -- Defined at Foo.hs:8:9 }}} Do you see the difference? In the former, the "prov_theta" equality constraint is explicit, but in the latter it's implicit. The exact thing happens for `DataCons`. It's handled via the `dcEqSpec` field. Essentially `PatSyn` should have a new field for the implicit equality constraints. And, just as for data consructors, we need to generate the equality constraints, and the existentials that are needed, when we process the signature. Use the code in `TcTyClsDecls.rejigConRes` (perhaps needs a better name). This is all pretty serious. Without fixing it, GADT-style pattern signatures are all but useless. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 06 Aug '15

06 Aug '15

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That is indeed very very bad. Never mind Safe Haskell -- it's just unsound. You didn't get a seg fault, but you very well might have. (For class instances it wouldn't be unsound, just possibly a bit incoherent.) I'm not sure what to do: 1. Prohibit `type instance` declarations in GHCi that overlap/override earlier ones? 2. Do (1) but also provide a way to purge the GHCi environment, so you can get back to a clean slate without restarting GHCi 3. Try to be clever: purge only functions (or whatever) whose types mention `T`. But it's tricky: what about data types mentioning `T`, and functions whose types use those data types... I incline to (2). Any other opinions? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10720: New GHC fails to specialize imported function
by GHC 06 Aug '15

06 Aug '15

#10720: New GHC fails to specialize imported function -------------------------------------+------------------------------------- Reporter: wyager | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X performance, inline, specialize | Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I just installed the new Haskell platform for OS X. It seems to have caused a major performance regression for a program I'm working on, making it well over 25x slower. The culprit appears to be that the new GHC (7.10.2) fails to specialize an imported function. If I manually add a SPECIALIZE pragma, performance goes back to around what it used to be. The code in question is located at https://github.com/wyager/HNet . As it stands, the code takes about 30 seconds to run on my machine. With the previous haskell-platform, it only took about .9 seconds. If I modify Operations.hs and uncomment the SPECIALIZE pragma, runtime goes down to about 1.1 seconds (still slower for some reason, but not awful). To test, compile with -O2 (as the program makes heavy use of Data.Vector, which requires -fspec-constr for performance). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10720> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6