November 2014 - ghc-tickets

[GHC] #9240: "read . show ≡ id" not satisfied by Data.Fixed
by GHC 02 Dec '14

02 Dec '14

#9240: "read . show ≡ id" not satisfied by Data.Fixed ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9213 | ------------------------------------+------------------------------------- As pointed out in #9213, the desired property "read . show ≡ id" is not satisfied for all resolutions. For instance, consider the following example: {{{ > data B7 > instance HasResolution B7 where resolution _ = 128 > 1.070 :: Fixed B7 1.062 > 1.062 :: Fixed B7 1.054 > read "1.070" :: Fixed B7 1.062 > read "1.062" :: Fixed B7 1.054 }}} This behaviour can be reproduced all the way back to GHC 7.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9818: Add `Natural` number type to `base`
by GHC 02 Dec '14

02 Dec '14

#9818: Add `Natural` number type to `base` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #3650 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- See original proposal at http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23300 which was generally met with unanimous support for adding such a type. Request for CLC-arbitration (and its conclusion) on two more or less controversial details lacking consensus: https://groups.google.com/forum/#!msg/haskell-core- libraries/CVylSkkHCWE/Cqn7VEgR24sJ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon`
by GHC 02 Dec '14

02 Dec '14

#9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As part of my work on #6018 I added new fields to `SynTyCon` data constructor of `TyCon` type. These fields only make sense for type families because we don't trace injectivity information for type synonyms. `SynTyCon` already has some fields that only make sense for type families. Richard suggests that `SynTyCon` is split into two separate constructors. With my implementation of injective type families this makes even more changes. I'm going to make that change in HEAD Real Soon Now so that I can rebase my work on top of it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9582: Associated Type Synonyms do not unfold in InstanceSigs
by GHC 02 Dec '14

02 Dec '14

#9582: Associated Type Synonyms do not unfold in InstanceSigs -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: InstanceSigs | Unknown/Multiple TypeFamilies | Type of failure: Architecture: Unknown/Multiple | None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE InstanceSigs, TypeFamilies #-} class C a where type T a m :: T a instance C Int where type T Int = String m :: String m = "bla" -- Method signature does not match class; it should be m :: T Int -- In the instance declaration for ‘C Int’ }}} As {{{T Int}}} is a synonym of {{{String}}}, {{{m :: String}}} should be a valid type signature alternative to {{{m :: T Int}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9757: Warn about derivable instances
by GHC 02 Dec '14

02 Dec '14

#9757: Warn about derivable instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC can derive a lot of instances by itself, and can sometimes (with `GeneralizedNewtypeDeriving`) do so better than anyone else. I'd like to be able to get a warning about any instance that's "obviously equivalent" to the one that would be derived, for some suitable values of "obviously" and "equivalent". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8304: more lenient operator sections (RelaxedSections extension)
by GHC 01 Dec '14

01 Dec '14

#8304: more lenient operator sections (RelaxedSections extension) -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | 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: | -------------------------------------+------------------------------------- Some operator sections are rejected which could have some meaning. {{{ (a ++ b ++ ) could mean \x -> a ++ b ++ c (++ a ++) could mean \x y -> x ++ a ++ y }}} The attached quasiquoter implements this, but for various reasons it would be better if ghc supported this directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9497: Silent typed holes
by GHC 01 Dec '14

01 Dec '14

#9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: typed holes, | Operating System: warnings | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have a UI feature request for -fwarn-typed-holes, currently there's two options: 1) typed holes are on (default) and GHC prints errors for types holes or 2) typed holes are off and GHC will print "not in scope" error and prematurely end compilation. When writing haskell, I frequently want to typecheck my code before it's completely implemented. Before I used undefined/error, which worked but I was always worried about accidentally forgetting an undefined somewhere. With typed holes this is no longer a problem, but unfortunately the warnings from typed holes are so verbose they drown out the other type errors. This makes typechecking during refactoring rather onerous. I propose adding a -fsilent-typed-holes and/or -ftreat-type-holes-as- undefined which enable typed holes, but silence any compile time warnings. It'd be nice if this flag treated holes as if "-fdefer-type-errors" was on, but ONLY for typed holes. This would let me compile the code and fix warnings, ignoring the holes while developing, while still assuring that, when I remove the flag and compile "for real" I get an error about typed holes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong
by GHC 01 Dec '14

01 Dec '14

#9833: GHCi suggestion for instance signature (InstanceSigs) is wrong -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- With `InstanceSigs` and `PolyKinds` enabled and the following type with kind `ĸ -> *`: {{{#!hs data NullableInterp a = NullI Bool }}} I want to make it an instance of `Alternative` and I decide to supply a signature for `empty`: {{{#!hs instance Alternative NullableInterp where empty :: NullableInterp a empty = undefined (<|>) = undefined }}} but GHCi complains with the following error: {{{#!hs % ghci -ignore-dot-ghci error.hs GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( error.hs, interpreted ) error.hs:14:12: Method signature does not match class; it should be empty :: forall a. NullableInterp a In the instance declaration for ‘Alternative NullableInterp’ Failed, modules loaded: none. Prelude> }}} Trying GHCi's suggestion (with appropriate extensions) doesn't help and I have to write `empty :: NullableInterp (a :: *)` for it to work. I'm not sure which behaviour is the right one but either it should have compiled or GHCi's suggestion should be `empty :: forall a. NullableInterp (a :: *)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9480: Segfault in GHC API code using Shelly
by GHC 01 Dec '14

01 Dec '14

#9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A segfault occurs when using the GHC API with Shelly. I do not know why. Here is a code snippet that triggers it: {{{#!hs import GHC import GHC.Paths ( libdir ) import DynFlags main = runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags $ dflags { hscTarget = HscInterpreted, ghcLink = LinkInMemory } imports <- mapM parseImportDecl ["import Shelly", "import Prelude"] setContext $ map IIDecl imports runStmt "shelly undefined" RunToCompletion }}} Note that on Mac OS X, this has no output whatsoever. The segfault occurs on Ubuntu 14.04, with `uname -a` outputting the following: {{{ Linux yed 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux }}} I cannot find any way to get this to work and have no idea what's up with this or why shelly triggers it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9480> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9186: GHC panic when compiling compdata
by GHC 01 Dec '14

01 Dec '14

#9186: GHC panic when compiling compdata ------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | 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: | ------------------------------------+------------------------------------- When testing ghc-7.8.2.20140609 with Stackage, I came across the following ghc panic: [51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, dist/build/Data/Comp/Ordering.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2.20140609 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc4836_0/ghc4836_257.so: undefined symbol: compdatazm0zi8zi1zi0_DataziCompziDeriveziUtils_zdwabstractConType_info Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install compdata-0.8.1.0 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30