- ghc-tickets - Haskell.org

[GHC] #11420: Incorrect links
by GHC 15 Jan '16

15 Jan '16

#11420: Incorrect links -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The links to the source tarballs on the page https://www.haskell.org/ghc/download_ghc_7_10_3 are incorrect. Instead of links to the source tarballs, the links to the sources of windows-extra are provided. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 15 Jan '16

15 Jan '16

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by bgamari): hvr, what is the status of this? Phab:D339 has been merged and we now always use `integer-gmp2` but we appear to build against `gmp-6.0.0-3` on Windows. Perhaps we should bump this so we can close this issue? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys,
by GHC 15 Jan '16

15 Jan '16

#11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- It would be great if there were a nice comprehensive Note (perhaps in `Module.hs`) describing the various identifiers which we have for modules, packages, units, etc. These might include, * `Package` * `PkgName` * `PkgKey` * `PkgId` * `UnitId` * `UnitKey` * Component? After writing this I found [[Commentary/Packages/Concepts]] but it would be great if this information found its way into a nice, central Note. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11388: Bad Windows PE handling in GHC runtime linker
by GHC 15 Jan '16

15 Jan '16

#11388: Bad Windows PE handling in GHC runtime linker -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Playing with `-fsplit-sections` on Windows I've found a pile of ancient (it was borrowed from Hugs interpreter code and I don't even know when was it created), absolutely redundant and plain wrong code in RTS linker. Technically it is a bug, but it doesn't break things when used with current Windows binutils with no special linker scripts involved. OTOH, it slows down runtime linker on Windows noticeably and thus can be considered as a performance bug. I've attached the patch which fixes this. The nice side-effect for existing users is that GHCi now loads compiled object code much faster on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11426: API Annotations: Detached parens annotations for infix function
by GHC 14 Jan '16

14 Jan '16

#11426: API Annotations: Detached parens annotations for infix function -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The code {{{#!hs module ParenFunBind where (foo x) y = x + y }}} results in the annotations for the `(` and `)` not being attached to anything in the final `ParsedSource` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11417: Missing context in Generics example
by GHC 14 Jan '16

14 Jan '16

#11417: Missing context in Generics example -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core | Version: 7.10.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Haddocks for `GHC.Generics` give an example of a default implementation using Generics: {{{#!hs class Encode a where encode :: a -> [Bool] default encode :: (Generic a) => a -> [Bool] encode x = encode' (from x) }}} The default signature is missing some context. It should read {{{#!hs default encode :: (Generic a, Encode' (Rep a)) => a -> [Bool] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11417> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11391: TypeError is fragile
by GHC 14 Jan '16

14 Jan '16

#11391: TypeError is fragile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this use of the new `TypeError` feature, {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, UndecidableInstances #-} {-# LANGUAGE UndecidableInstances #-} import Data.Kind import GHC.TypeLits (TypeError, ErrorMessage(..)) type family Resolve (t :: Type -> Type) :: Type -> Type where Resolve _ = TypeError (Text "ERROR") }}} ==== The okay case ==== Given something like, {{{#!hs testOK :: Resolve [] Int testOK = [] }}} we find that things work as expected, {{{ • ERROR • In the expression: [] :: Resolve [] Int In an equation for ‘testOK’: testOK = [] :: Resolve [] Int }}} This is what we would expect. ==== The bad case ==== However, it is very easy to fool GHC into not yielding the desired error message. For instance, {{{#!hs testNOTOK1 :: Resolve [] Int testNOTOK1 = () }}} gives us this a unification error, {{{ • Couldn't match type ‘()’ with ‘(TypeError ...)’ Expected type: Resolve [] Int Actual type: () }}} This clearly isn't what we expected. ==== The tricky case ==== Another way we can fool the typechecker is to make it attempt instance resolution on our `TypeError`, {{{#!hs testNOTOK2 :: Resolve [] Int testNOTOK2 = 1 }}} Which results in, {{{ • No instance for (Num (TypeError ...)) arising from the literal ‘1’ • In the expression: 1 In an equation for ‘testNOTOK2’: testNOTOK2 = 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11381: Put injective type families in a separate language extension
by GHC 14 Jan '16

14 Jan '16

#11381: Put injective type families in a separate language extension -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #6018 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Injective type families should only be enabled when language extension `InjectiveTypeFamilies` is specified. This extension should imply `TypeFamilies`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7245: INLINEing top-level patterns causes ghc to emit 'arity missing' traces
by GHC 14 Jan '16

14 Jan '16

#7245: INLINEing top-level patterns causes ghc to emit 'arity missing' traces -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7245#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7245: INLINEing top-level patterns causes ghc to emit 'arity missing' traces
by GHC 14 Jan '16

14 Jan '16

#7245: INLINEing top-level patterns causes ghc to emit 'arity missing' traces -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): This still applies to 8.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7245#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0