- ghc-tickets - Haskell.org

[GHC] #10615: Panic; no skolem info (partial type signatures)
by GHC 05 Aug '15

05 Aug '15

#10615: Panic; no skolem info (partial type signatures) -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This rather minimal program {{{#!hs f :: _ => _f f = const }}} results in this: {{{ GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) Panic.hs:1:6: Found hole ‘_’ with inferred constraints: () To use the inferred type, enable PartialTypeSignatures In the type signature for ‘f’: _ => _f Panic.hs:2:5: Couldn't match expected type ‘_f’ with actual type ‘a0 -> b0 -> a0’ ‘_f’ is untouchable inside the constraints () bound by the inferred type of f :: _f at Panic.hs:2:1-9ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): No skolem info: _f_alF[sk] }}} The newest open bugs (that reporter could find at the time of reporting) with "no skolem info" in their description are #10404 and #10432. The newest bug (which is closed) is #10503. It seems likely, though, that the above comes from the PartialTypeSignatures implementation (considering the simplicity of the repro). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie
by GHC 05 Aug '15

05 Aug '15

#10724: ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie -------------------------------------+------------------------------------- Reporter: martinvlk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I copy/paste text from a ghci instance running in the terminal, quite often it stops responding with the following message: <stdin>: hGetChar: hardware fault (Input/output error) I then have to kill it (Ctrl-C) and restart. It's GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help but I remember the same was happening in 7.10.1 too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10704: Can't lookup fixities of infix types in Template Haskell
by GHC 05 Aug '15

05 Aug '15

#10704: Can't lookup fixities of infix types in Template Haskell -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently, Template Haskell allows you to reify the fixity of regular functions, typeclass functions, and data constructors: {{{ λ> import Language.Haskell.TH λ> $(reify '($) >>= stringE . show) "VarI GHC.Base.$ (ForallT [KindedTV a_822083586 StarT,KindedTV b_822083587 (ConT GHC.Prim.OpenKind)] [] (AppT (AppT ArrowT (AppT (AppT ArrowT (VarT a_822083586)) (VarT b_822083587))) (AppT (AppT ArrowT (VarT a_822083586)) (VarT b_822083587)))) Nothing (Fixity 0 InfixR)" λ> $(reify '(+) >>= stringE . show) "ClassOpI GHC.Num.+ (ForallT [KindedTV a_1627404054 StarT] [AppT (ConT GHC.Num.Num) (VarT a_1627404054)] (AppT (AppT ArrowT (VarT a_1627404054)) (AppT (AppT ArrowT (VarT a_1627404054)) (VarT a_1627404054)))) GHC.Num.Num (Fixity 6 InfixL)" λ> $(reify '(:%) >>= stringE . show) "DataConI GHC.Real.:% (ForallT [KindedTV a_1627412324 StarT] [] (AppT (AppT ArrowT (VarT a_1627412324)) (AppT (AppT ArrowT (VarT a_1627412324)) (AppT (ConT GHC.Real.Ratio) (VarT a_1627412324))))) GHC.Real.Ratio (Fixity 9 InfixL)" }}} However, you can't do the same for infix typeclasses, type constructors, or type families: {{{ λ> :set -XTypeOperators -XTypeFamilies -XMultiParamTypeClasses λ> class a :=> b; infixr 5 :=> λ> $(reify ''(:=>) >>= stringE . show) "ClassI (ClassD [] Ghci5.:=> [KindedTV a_1627424666 StarT,KindedTV b_1627424667 StarT] [] []) []" λ> type a :+: b = Either a b; infixr 5 :+: λ> $(reify ''(:+:) >>= stringE . show) "TyConI (TySynD Ghci7.:+: [KindedTV a_1627426783 StarT,KindedTV b_1627426784 StarT] (AppT (AppT (ConT Data.Either.Either) (VarT a_1627426783)) (VarT b_1627426784)))" λ> $(reify ''(:*:) >>= stringE . show) "FamilyI (FamilyD TypeFam Ghci9.:*: [KindedTV a_1627426938 StarT,KindedTV b_1627426939 StarT] (Just StarT)) []" }}} We should add a {{{Fixity}}} field to {{{ClassI}}}, {{{TyConI}}}, and {{{FamilyI}}} to make them consistent with the other {{{Info}}} constructors that allow for infix things. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10706: Make -fcpr-off a dynamic flag
by GHC 05 Aug '15

05 Aug '15

#10706: Make -fcpr-off a dynamic flag -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: feature | Status: new request | 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 Revisions: | -------------------------------------+------------------------------------- I've run into a situation where I wanted to turn off CPR analysis for a single module in my project, but could not do that because {{{-fcpr-off}}} is a static flag. I will supply a patch that makes {{{-fcpr-off}}} a dynamic flag. From what I understand, this would also bring us one step closer to the desired goal of getting rid of static flags entirely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #2747: Excessive Memory Usage: space leak with foldl' on Integer
by GHC 05 Aug '15

05 Aug '15

#2747: Excessive Memory Usage: space leak with foldl' on Integer -------------------------------------+--------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Test Case: | -------------------------------------+--------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"dd7e1880ae078a2d9f254dc5d8f330121e0ec291/ghc" dd7e1880/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dd7e1880ae078a2d9f254dc5d8f330121e0ec291" Add framework flags when linking a dynamic library This fixes the GHC side of trac #10568. So `cabal install --ghc-options="-framework GLUT" GLUT` creates a correctly linked GLUT.dylib. We still need to explictly pass `--ghc-options="-framework GLUT"` because the Cabal side #10568 is not fixed. Update: the Cabal side of #10568 is fixed by [Cabal#2747](https://github.com/haskell/cabal/pull/2747) Test Plan: validate Reviewers: austin, rwbarton, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1115 GHC Trac Issues: #10568 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2747#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #367: Infinite loops can hang Concurrent Haskell
by GHC 05 Aug '15

05 Aug '15

#367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler | allocation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | concurrent/should_run/T367, | concurrent/should_run/T367_letnoescape Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"4c55f14d0ab0f2b099c475a9810012f645bb059e/ghc" 4c55f14d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c55f14d0ab0f2b099c475a9810012f645bb059e" users_guide: Add note about #367 to Bugs section This is a long-standing bug and should be mentioned in the users guide, as noted in #10639. Test Plan: Carefully check language. Reviewers: simonpj, rwbarton, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1127 GHC Trac Issues: #10639, #367 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/367#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1062: Bad output from Text.PrettyPrint.HughesPJ
by GHC 05 Aug '15

05 Aug '15

#1062: Bad output from Text.PrettyPrint.HughesPJ -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 6.6 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: pp1 Blocked By: | Blocking: Related Tickets: #669 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #669 Comment: Replying to [comment:3 thorkilnaur]: > This is actually a duplicate of #669. Reclosing. thorkilnaur and benedikt were the last ones to truly understand the pretty library, and I trust their judgement on this. Replying to [comment:6 igloo]: > Reopening, as this ticket is for the bad output of the pp1 test. The pp1 test is nowhere to be found, and the pretty bug tracker is at https://github.com/haskell/pretty/issues nowadays. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1062#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9430: implement more arithmetic operations natively in the LLVM backend
by GHC 05 Aug '15

05 Aug '15

#9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Runtime than a day) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There are a number of arithmetic operations that have native implementations on x86 but use the generic fallback on LLVM. Implementing these with LLVM intrinsics could improve small Integer performance on ARM substantially! {{{ MO_Add2 @llvm.uadd.with.overflow.* MO_AddIntC @llvm.sadd.with.overflow.* MO_SubIntC @llvm.ssub.with.overflow.* MO_U_Mul2 mul i64/i128? MO_U_QuotRem2 udiv i64/i128? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

Re: [GHC] #1290: ghc runs preprocessor too much
by GHC 05 Aug '15

05 Aug '15

#1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 6.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: ⊥ => 7.12.1 Comment: What if this information was cached in the interface file? Essentially, interface files should contain enough information for us to construct a `ModSummary`, and they are as recent as the source file we can just use this directly. (And we're going to read the interface file anyway shortly thereafter do check for recompilation avoidance.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1290#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs
by GHC 05 Aug '15

05 Aug '15

#7666: excessive space and time usage for rendering (somewhat) deeply nested Docs -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.6.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): To be fair: `tpdb` probably had less dependencies when you submitted this bug. It also depends on `wl-pprint-text` now, perhaps because pretty is too slow/uses too much memory... Anyway, please open a bug on the pretty bug tracker, it will hopefully get more attention there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7666#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0