June 2014 - ghc-tickets

[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] #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

[GHC] #8100: Standalone deriving using template haskell
by GHC 01 Dec '14

01 Dec '14

#8100: Standalone deriving using template haskell ------------------------------------+------------------------------------- Reporter: acube | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, there seems to be no support for standalone deriving in TemplateHaskell: {{{ Prelude Data.Typeable Language.Haskell.TH> :set -XStandaloneDeriving Prelude Data.Typeable Language.Haskell.TH> data Weird a (b :: * -> * -> *) c = Weird Prelude Data.Typeable Language.Haskell.TH> runQ $ [d| deriving instance Typeable Weird |] [] }}} ''Use case'': The library [http://hackage.haskell.org/package/typeable-th typeable-th] can already generate Typeable instances using TH for GHC 7.4 and 7.6. To add support for GHC 7.8 in a way that the user doesn't have to care about the version, there has to be a way to make Typeable instances via TH in GHC 7.8. This is currently impossible, but with StandaloneDeriving support for TH, it would be possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9005: Ship default bash completion file with ghc
by GHC 01 Dec '14

01 Dec '14

#9005: Ship default bash completion file with ghc ------------------------------------+------------------------------------- Reporter: td123 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: None | 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: | ------------------------------------+------------------------------------- Now that ticket #7843 has been closed, it would be great to ship a default implementation of a bash completion file for ghc. Since there isn't a standard location to install completion files across distros, it might be good to have an optional flag during configure to specify a location and if one is specified, install the bash completion file into that location. The following links provide implementations that have worked for me: http://www.reddit.com/r/haskell/comments/236qkb/autocomplete_command_line_o… https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8815: confusing language in error message
by GHC 30 Nov '14

30 Nov '14

#8815: confusing language in error message ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Late last night I was finding myself very confused by the following (in retrospect obvious error message) {{{ src/Numerical/OpenBLAS/BLAS.hs:41:44: A pattern match on a GADT requires GADTs or TypeFamilies In the pattern: SRow In the pattern: DenseMatrix SRow _ _ _ _ In an equation for ‛encodeNiceOrderHelper’: encodeNiceOrderHelper (DenseMatrix SRow _ _ _ _) = encodeOrder BLASRowMajor }}} the error is correct per se, but reading (at least late at night) made me think "wait, how is my type not a GADT or TypeFamily?!!?!" I'm thinking (perhaps ) that ``` A pattern match on a GADT requires GADTs or TypeFamilies `` ` could perhaps be more clearly communicated as ```A pattern match on a GADT requires that GADTs or TypeFamilies Language extensions be enabled in the use site module``` (or something similar) relatedly: whats the current reasoning for why GADT related matching logic isn't enabled in client modules that use GADTs? (i'm not questioning it, just wondering why) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8323: explore ways to possibly use more tag bits in x86_64 pointers
by GHC 28 Nov '14

28 Nov '14

#8323: explore ways to possibly use more tag bits in x86_64 pointers ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- on x86_64, pointers only use 48 bits! currently we use 3bits for tagging / arity etc info on x86_64, we should explore more uses! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault
by GHC 28 Nov '14

28 Nov '14

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I am getting segfaults when a statically linked executable uses a GHC API. When the same executable is however dynamically linked it runs without error. In case of the statically-linked version, I think that one of GHC API functions that tries to do dynamic-linking is causing the segfault. The reason why I think this, is because the segfault shows up when Template-Haskell is used, or when {{{ {-# ANN ... #-} }}} annotations are used. An example of this strange behaviour can be shown using haddock, and running it on the source-code for the lens library [1]: {{{ ~/Documents/devel/lens/src (master *)$ haddock -v3 Control/Lens/Internal/ByteString.hs Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Setter... Creating interface... 100% ( 3 / 3) in 'Control.Lens.Internal.Setter' <MORE LOG MESSAGE> Checking module Control.Lens.Reified... Creating interface... 100% ( 20 / 20) in 'Control.Lens.Reified' Checking module Control.Lens.Setter... Bus error: 10 <-- SEGFAULT }}} And the GDB output: {{{ (gdb) run -v3 Control/Lens/Internal/ByteString.hs Starting program: /Users/christiaan/.ghc- config/cabal/7.7.20130924/bin/haddock -v3 Control/Lens/Internal/ByteString.hs Reading symbols for shared libraries +++.............................. done Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Setter... Creating interface... 100% ( 3 / 3) in 'Control.Lens.Internal.Setter' <MORE LOG MESSAGES> Checking module Control.Lens.Reified... Creating interface... 100% ( 20 / 20) in 'Control.Lens.Reified' Checking module Control.Lens.Setter... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x000000010828b982 0x000000010828b982 in ?? () }}} I should note that until now I've been unable to produce a _small_ test case that shows the above behaviour. The statically linked haddock actually runs successfully on many packages. The lens[1] package is the first widely used library that I've been able to get haddock to exhibit the above behaviour. Also, when I built a dynamically-linked version of haddock, it runs succesfully for the above test-case (and the other test-cases where the statically-linked version would give a segfault). The source-code for lens[1] contains many {{{ {-# ANN ... #-} }}} annotations; removing all those annotations make the statically-linked version of haddock run successfully, with out segfaults. Halfway through removing the {{{ {-# ANN ... #-} }}} annotation, I also encountered the following error: {{{ Checking module Control.Lens.Fold... haddock: internal error: ARR_WORDS object entered! (GHC version 7.7.20130924 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} I've also encountered the segfault while running the statically-linked haddock on my own clash library [2]. In this case I think it might have something to do with the use of template-haskell. Again, running the dynamically-linked version of haddock does not show any problems. Here is some extra information about my development environment:[[BR]] OS: OS X 10.8.5[[BR]] X-Code: XCode CL-Tools 4.6.2[[BR]] GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546)[[BR]] Output of {{{make show VALUE=GhcLibWays}}}: v dyn[[BR]] build.mk: {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 HADDOCK_DOCS = NO }}} I create statically-linked binaries by setting {{{executable-dynamic}}} in {{{.cabal/config}}} to {{{False}}}[[BR]] I create dynamically-linked binaries by setting {{{executable-dynamic}}} in {{{.cabal/config}}} to {{{True}}}[[BR]] I created the {{{haddock}}} executables by running {{{cabal install}}} in {{{"up-to-date build tree of GHC"/utils/haddock}}} [1] https://github.com/ekmett/lens[[BR]] [2] http://hackage.haskell.org/package/clash-lib -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8338: Incoherent instances without -XIncoherentInstances
by GHC 25 Nov '14

25 Nov '14

#8338: Incoherent instances without -XIncoherentInstances ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Consider the following 4 modules: {{{ {-# LANGUAGE GADTs #-} module A where data One = One data ShowInstFor a = Show a => MkSIF incoherent :: ShowInstFor One -> ShowInstFor One -> String incoherent MkSIF MkSIF = show One }}} {{{ module B where import A instance Show One where show _ = "from module B" fromB :: ShowInstFor One fromB = MkSIF }}} {{{ module C where import A instance Show One where show _ = "from module C" fromC :: ShowInstFor One fromC = MkSIF }}} {{{ module D where import A import B import C oops1 = incoherent fromB fromC oops2 = incoherent fromC fromB }}} According to ghci, `oops1` is `"from moduleB"` and `oops2` is `"from module C"`. This seems bad. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8044: "Inaccessible code" error reported in wrong place
by GHC 24 Nov '14

24 Nov '14

#8044: "Inaccessible code" error reported in wrong place -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: GADTs | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Here is my file `Bug.hs`: {{{ {-# LANGUAGE GADTs, TypeFamilies #-} module Bug where data X a where XInt :: X Int XBool :: X Bool XChar :: X Char type family Frob a where Frob Int = Int Frob x = Char frob :: X a -> X (Frob a) frob XInt = XInt frob _ = XChar }}} Compiling this file produces the error {{{ Bug.hs:15:6: Couldn't match type ‛Int’ with ‛Char’ Inaccessible code in a pattern with constructor XInt :: X Int, in an equation for ‛frob’ In the pattern: XInt In an equation for ‛frob’: frob XInt = XInt }}} The line/column number single out the pattern `XInt` in the first clause of the function `frob`. But, the real problem (as I see it), is the right- hand side of the ''second'' clause of `frob`. Indeed, when I comment out the second line of the function, the error goes away, even though it was reported on the first line. I do not believe that this error is caused by closed type families, per se, because I have run across it without them, just in code that was too hard to pare down enough to make a bug report out of. This was tested on 7.7.20130702. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8046: Make the timer management scale better across multicore
by GHC 22 Nov '14

22 Nov '14

#8046: Make the timer management scale better across multicore ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- A recent commit {{{ commit e843e73690f828498f6e33bb89f47a50c3ab2ac9 Author: Ian Lynagh <ian(a)well-typed.com> Date: Sat Jun 8 20:19:59 2013 +0100 IO manager: Edit the timeout queue directly, rather than using an edit list Fixes #7653. }}} undid an optimization to the management of timeouts (to fix a bug, which is good). We should check how much this hurt performance, but it might be better to rewrite the timeout management altogether. The current scheme scales poorly to several cores. We should probably have one priority queue per core and use an efficient mutable data structure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2