June 2014 - ghc-tickets

Re: [GHC] #703: all binaries built by ghc have executable stacks
by GHC 30 Jun '14

30 Jun '14

#703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Changes (by ezyang): * milestone: 6.6.1 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/703#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9245: In absence of recursive imports, hs-boot files not checked for consistency
by GHC 30 Jun '14

30 Jun '14

#9245: In absence of recursive imports, hs-boot files not checked for consistency -----------------------------------+--------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Example: B.hs-boot {{{ module B where b :: Bool }}} A.hs {{{ module A where import {-# SOURCE #-} B a = b }}} B.hs {{{ module B where }}} Main.hs {{{ import A main = print a }}} Compilation: {{{ ghc -c B.hs-boot ghc -c A.hs ghc -c B.hs ghc -c Main.hs ghc -o main A.o B.o Main.o }}} Error: {{{A.o:(.text+0x79): undefined reference to `B_b_closure' A.o: In function `A_a_srt': (.data+0x0): undefined reference to `B_b_closure' collect2: error: ld returned 1 exit status }}} The culprit seems to be this code: {{{ -- OK, so we're in one-shot mode. -- In that case, we're read all the direct imports by now, -- so eps_is_boot will record if any of our imports mention us by -- way of hi-boot file { eps <- getEps ; case lookupUFM (eps_is_boot eps) (moduleName mod) of { Nothing -> return emptyModDetails ; -- The typical case Just (_, False) -> failWithTc moduleLoop ; -- Someone below us imported us! -- This is a loop with no hi-boot in the way Just (_mod, True) -> -- There's a hi-boot interface below us }}} but I am not 100% sure what the correct new logic is yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5722: GHC inlines class method forever
by GHC 30 Jun '14

30 Jun '14

#5722: GHC inlines class method forever ---------------------------------------+----------------------------------- Reporter: benmachine | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by klao): * cc: klao@… (added) Comment: One aspect in which the #9235 example is different, is that it triggers the bug even with `-O0`. (I'm not sure if this is important or not.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5722#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5722: GHC inlines class method forever
by GHC 30 Jun '14

30 Jun '14

#5722: GHC inlines class method forever ---------------------------------------+----------------------------------- Reporter: benmachine | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by simonpj): See #9235 for another example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5722#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #703: all binaries built by ghc have executable stacks
by GHC 30 Jun '14

30 Jun '14

#703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): I did write a test, but we never figured out why Fedora 64bit was still having executable stacks, and then the problem went away. So... I'm not really sure what was going on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/703#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #703: all binaries built by ghc have executable stacks
by GHC 30 Jun '14

30 Jun '14

#703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by tibbe): Could someone please write a test so this doesn't regress again? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/703#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8883: FlexibleContexts checking should happen also on inferred signature
by GHC 30 Jun '14

30 Jun '14

#8883: FlexibleContexts checking should happen also on inferred signature ------------------------------------+------------------------------------- Reporter: Blaisorblade | 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: | ------------------------------------+------------------------------------- I assume that if a program typechecks, adding any missing top-level signature inferred by GHC should be a meaning-preserving transformation and yield a new program which typechecks. (Please correct me if I'm wrong). But I've found a violation: namely, given enough other extensions (I think TypeFamilies is the relevant one), GHC will infer signatures which would require FlexibleContexts! Arguably, either those signatures should be rejected in the first place with a special error message (since GHC is not supposed to show code the user didn't write in error messages), or TypeFamilies should imply FlexibleContexts (or a restricted form which is sufficient for what TypeFamilies produces - namely, constraints can contain type families in place of raw type variables). Here's an example - without FlexibleContexts it does not typecheck , unless you comment out the signature of fold and unfold. Those signatures where produced by GHCi (with :browse) in the first-place. {{{#!haskell {-# LANGUAGE TypeFamilies, DeriveFunctor, NoMonomorphismRestriction #-} -- , FlexibleContexts data Fix f = In { out :: f (Fix f) } data Expr = Const Int | Add Expr Expr data PFExpr r = ConstF Int | AddF r r deriving Functor type Expr' = Fix PFExpr class Regular0 a where deepFrom0 :: a -> Fix (PF a) deepTo0 :: Fix (PF a) -> a type family PF a :: * -> * type instance PF Expr = PFExpr instance Regular0 Expr where deepFrom0 = In . (\expr -> case expr of Const n -> ConstF n Add a b -> AddF (deepFrom0 a) (deepFrom0 b)) deepTo0 = (\expr' -> case expr' of ConstF n -> Const n AddF a b -> Add (deepTo0 a) (deepTo0 b)) . out class Regular a where from :: a -> PF a a to :: PF a a -> a instance Regular Expr where from expr = case expr of Const n -> ConstF n Add a b -> AddF a b to expr' = case expr' of ConstF n -> Const n AddF a b -> Add a b -- But in fact, the construction is just an instance of fold. fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b unfold :: (Functor (PF b), Regular b) => (a -> PF b a) -> a -> b fold f = f . fmap (fold f) . from unfold f = to . fmap (unfold f) . f }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9250: let makes function too much specific
by GHC 30 Jun '14

30 Jun '14

#9250: let makes function too much specific --------------------------+------------------------------------------------ Reporter: | Owner: KommuSoft | Status: new Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: x86_64 | Blocking: (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Say you define a `myadd` function: let myadd x y = x + y Then the type is `Num a => a -> a -> a`. If on the other hand, you define the method using currying: let myadd2 \x -> \y -> x + y The type is more specific: `Integer -> Integer -> Integer`. Strangely enough `:t \x -> \y -> x + y` returns the more general form. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9250> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 29 Jun '14

29 Jun '14

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184, 8235 Blocking: | Related Tickets: #9221 -------------------------------------+------------------------------------ Changes (by hvr): * related: => #9221 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:62> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1970: ghci -hide-all-packages gives bad error message
by GHC 29 Jun '14

29 Jun '14

#1970: ghci -hide-all-packages gives bad error message ----------------------------+------------------------------- Reporter: dfranke | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Difficulty: Unknown | Test Case: ----------------------------+------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"dab0fa06fa33eeb45cef16c06c41d6c45b102451/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dab0fa06fa33eeb45cef16c06c41d6c45b102451" Update Cabal to BinaryLiterals-aware 1.20 version In 1c0b5fdc9f2b6ea8166cc565383d4cd20432343c (re #9224) `BinaryLiterals` was temporarily added to T4437's `expectedGhcOnlyExtensions` list. This can now reverted as Cabal has been made aware of `BinaryLiterals` (see haskell/cabal#1970 and haskell/cabal#1972). updates Cabal submodule Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1970#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0