June 2015 - ghc-tickets

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): I just read the proposed documentation on Phabricator. There is something that I think is dissatisfying with the implementation. As I understand it, the contract expressed by an empty data type is that there should be no value inhabiting it. So, if a piece of program ever builds one, the blame should be assigned to that piece of code. However, it does not appear that the current implementation does this. Eg: (error "oops" :: Foo) `compare` (error "oops" :: Foo) should fail with "oops", not "compare on empty data type Foo" Similarly, a Read instance makes no sense imho. Please, consider forcing the arguments in all these instances, before failing. Finally, I realise that my original report was misleading. I am sorry for that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 16 Jun '15

16 Jun '15

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by osa1): * cc: omeragacan@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Jun '15

16 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): I think in the worst case we should be able to consider empty types as enums and fix #2578 in a later stage -- e.g. while generating the "table". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10534: Data families + Coercible = unsafeCoerce
by GHC 16 Jun '15

16 Jun '15

#10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} module A where import Data.Coerce data family DF a silly :: Coercible (DF a) (DF b) => a -> b silly = coerce }}} {{{ {-# LANGUAGE TypeFamilies #-} module B where import A newtype instance DF a = MkDF () unsafeCoerce :: a -> b unsafeCoerce = silly }}} I get {{{ [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) Ok, modules loaded: A, B. }}} Eep! Happily, the fix is very very simple: `TyCon.isDistinctAlgRhs` should return `False` for `DataFamilyTyCon`s. This fix is already in-flight for HEAD in Phab:D968, but this ticket serves to correct this problem in 7.10.2 before the release. Patch coming very shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 16 Jun '15

16 Jun '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10532: Unnecessary constraints when using overlapping instances
by GHC 16 Jun '15

16 Jun '15

#10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code compiles just fine: {{{ class Foo a where foo :: a -> Int instance Foo a where foo _ = 5 f :: a -> Int f = foo }}} But if we modify the code to use overlapping instances like so: {{{ class Foo a where foo :: a -> Int instance {-# OVERLAPS #-} Foo Int where foo = id instance {-# OVERLAPPABLE #-} Foo a where foo _ = 5 f:: a -> Int f = foo }}} We get the following compiler message: {{{ Overlapping instances for Foo a arising from a use of ‘foo’ Matching instances: instance [overlappable] Foo a -- Defined at ... instance [overlap ok] Foo Int -- Defined at ... (The choice depends on the instantiation of ‘a’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) }}} Including the constraint in the type signature makes the problem go away, but the constraint shouldn't be needed. In most use cases this wouldn't be a big deal, but it's making my type signatures much messier looking than they actually are. Adding IncoherentInstances as the error message suggests gives the instance I don't want. Weirdly, I get different instances depending on whether the constraint is in the type signature or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10451: Constraint tuple regression in HEAD
by GHC 16 Jun '15

16 Jun '15

#10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple ConstraintKinds | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following file works in GHC 7.10.1, but fails in HEAD: {{{ {-# LANGUAGE ConstraintKinds #-} module ConstraintKinds where type ManyEq a = (Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a -- Comment this line to make compilation succeed in HEAD ) }}} This is most likely due to ffc21506894c7887d3620423aaf86bc6113a1071, which has set a limit on constraint tuples to size `8`. I think we should either: - increase the size limit on constraint tuples to be the same as normal tuples (`62`), or, - automatically nest constraint kinds beyond 8-tuples, or, - carefully document this limitation for the next release. Note that I encountered this limitation in my own code that I and others actually use: http://hackage.haskell.org/package/clash- prelude-0.7.5/docs/src/CLaSH-Sized-Fixed.html#ENumSFixedC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr
by GHC 16 Jun '15

16 Jun '15

#10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHC rejects Test Case: | valid program Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- dynComipleExpr will accept invalid expr or reject valid expr because it compiles the expr as `"let _dynComipleExpr = (" ++ expr ++ ")"`. {{{#!hs -- tail -n 15 Test.hs forM_ exprs $ \expr -> handleSourceError printException $ do dyn <- dynCompileExpr expr liftIO $ print dyn where exprs = [ "" , "(),()" , "()" , "\"test\"" , unlines [ "[()]" , " :: [()]" ] ] -- ./Test /lib/ghc <<()>> <<((),())>> <<()>> <<[Char]>> <interactive>:2:2: parse error (possibly incorrect indentation or mismatched brackets) }}} As `:def` and `:cmd` uses `compileExpr`, they have the same problem: {{{ GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :{ Prelude| :cmd return $ unlines Prelude| [ "1" Prelude| , "2" Prelude| ] Prelude| :} <interactive>:2:3: parse error (possibly incorrect indentation or mismatched brackets) Prelude> import Prelude (return, id, ShowS, IO) Prelude> :cmd return "0" <interactive>:1:42: Not in scope: type constructor or class ‘String’ Prelude> type String = ShowS Prelude> :cmd return id zsh: segmentation fault (core dumped) ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 16 Jun '15

16 Jun '15

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications] Section 2.3, for why types can (legitimately I fear) blow up. I'm not say that is what is happening here, but it might be similar. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8785: Replace hooks API in the RTS with something better
by GHC 16 Jun '15

16 Jun '15

#8785: Replace hooks API in the RTS with something better ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hooks rely on static linking behaviour which doesn't always work: we have to disable -Bsymbolic for the RTS on Linux (see `compiler/main/SysTools.lhs`) and it apparently doesn't work at all on Mac (#8754). So instead of hooks we should be passing in information when we initialize the RTS, like we already do for some other things (`-rtsopts` etc.). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3