July 2015 - ghc-tickets

[GHC] #10548: Support PartialTypeSignatures in Template Haskell
by GHC 20 Jul '15

20 Jul '15

#10548: Support PartialTypeSignatures in Template Haskell -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently Template Haskell cannot emit [https://hackage.haskell.org/package/template-haskell-2.10.0.0/docs /Language-Haskell-TH-Syntax.html#t:Type Type]s with wildcards as in [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures PartialTypeSignatures]. A data constructor for wildcards (eg. {{{WildcardT (Maybe Name)}}}) could be added to [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#t:Type Type], which would be converted to wildcards in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10638: quoting and Template Haskell handling for prim and javascript foreign imports broken
by GHC 20 Jul '15

20 Jul '15

#10638: quoting and Template Haskell handling for prim and javascript foreign imports broken -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 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: | -------------------------------------+------------------------------------- In GHC 7.10.1, Template Haskell support was added for all calling conventions. Unfortunately a few cases are unhandled, which makes the TH code treat the `prim` and `javascript` calling conventions as if they were C calling conventions, adding the `static` keyword and running them through `parseCImport`. This is particularly bad for `javascript` imports, since most JS imports aren't valid C imports, so they get rejected. I'm testing a fix for this that I'll submit later today. I hope this is in time for 7.10.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10529: hpc: Improve error messages in readMix
by GHC 20 Jul '15

20 Jul '15

#10529: hpc: Improve error messages in readMix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Code | Version: 7.10.1 Coverage | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See https://hackage.haskell.org/package/hpc-0.6.0.2/docs/src/Trace-Hpc- Mix.html#readMix The generic `error $ "can not find " ++ modName ++ " in " ++ show dirNames` error message is used for all kinds of cases, for example when `h == tixModuleHash tix` isn't true. It would be very helpful if the error message could be specific for these cases (e.g. "hashes don't agree") instead of being a catch-all for all `Nothing`s. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7478: setSessionDynFlags does not always work
by GHC 20 Jul '15

20 Jul '15

#7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ghc- | api/T7478 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1017 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: T7478 is marked as expect_broken for darwin. Should that be changed now? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10624: th/T10279 testcase is broken
by GHC 20 Jul '15

20 Jul '15

#10624: th/T10279 testcase is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang 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: | -------------------------------------+------------------------------------- On Debian 7, x86_64. {{{ Actual stderr output differs from expected: --- ./th/T10279.stderr 2015-07-06 17:16:38.923135777 -0400 +++ ./th/T10279.comp.stderr 2015-07-09 08:29:06.443205994 -0400 @@ -1,8 +1,7 @@ -T10279.hs:10:10: - Failed to load interface for ‘A’ - no package key matching ‘rts-1.0’ was found - (This package key looks like the source package ID; - the real package key is ‘rts’) - In the expression: (rts-1.0:A.Foo) - In an equation for ‘blah’: blah = (rts-1.0:A.Foo) +T10279.hs:10:8:ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.10.1.20150708 for x86_64-unknown-linux): + qual_pkg rts-1.0 + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + *** unexpected failure for T10279(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10094: Template Haskell cannot represent type wildcards
by GHC 20 Jul '15

20 Jul '15

#10094: Template Haskell cannot represent type wildcards -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: GHC rejects Keywords: | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There does not appear to be a way for Template Haskell code to generate partial type signature wildcards. The type quasiquote `[t|_|]` results in `Wildcard not allowed`, and use in an expression quasiquote like `[|() :: _|]` results in `Exotic form of type not (yet) handled by Template Haskell _`. It would be useful if TH code could partially constrain the type of the expressions it was generating, without needing to determine the type completely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7861: deferred type error with rankNTypes
by GHC 20 Jul '15

20 Jul '15

#7861: deferred type error with rankNTypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time | Test Case: crash | typecheck/should_run/T7861 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"4c96e7cf56fc67ad09efaf8c5de1c8d7a0f5cedd/ghc" 4c96e7cf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c96e7cf56fc67ad09efaf8c5de1c8d7a0f5cedd" Testsuite: add ImpredicativeTypes to T7861 (#7861) The test was failing with: T7861: T7861.hs:15:13: Cannot instantiate unification variable ‘t0’ with a type involving foralls: A a0 -> a0 GHC doesn't yet support impredicative polymorphism In the first argument of ‘seq’, namely ‘f’ In a stmt of a 'do' block: f `seq` print "Hello 2" It requires ImpredicativeTypes, at least since 7.8, because we instantiate seq's type (c->d->d) with f's type (c:= (forall b. a) -> a), which is polymorphic (it has foralls). I simplified the test a bit by removing the type synonym, and verified that ghc-7.6.3 still panics on this test. Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1080 GHC Trac Issues: #7861 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7861#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10649: Performance issue with unnecessary reboxing
by GHC 20 Jul '15

20 Jul '15

#10649: Performance issue with unnecessary reboxing -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Depending on number of fields in a structure (A and F), $fBA_$cfoo or $fBF_$cfoo will or will not be using $w$cfoo for 16 fields it uses it, for 12 - not With lazy fields behaviour, it starts using $w$cfoo around 100-200 fields. Adding -funfolding-use-threshold=90 helps in this case, but given enough fields (about 50 of them, of different types) value of 1000000000 is not helping and with very cheap operation (like addition or allocation of cons-like structure) overhead from sending those parameters via stack into worker becomes very significant - I have code that works ~3-5 times slower. This issue is not specific to generics, I can provide more examples if necessary {{{#!hs {-# LANGUAGE FlexibleContexts, FlexibleInstances, DeriveGeneric, DefaultSignatures #-} {-# LANGUAGE TypeOperators, BangPatterns #-} {-# OPTIONS -funbox-strict-fields -ddump-to-file -ddump-simpl -ddump-stg -dsuppress-all -ddump-asm #-} import Data.Word import GHC.Generics data A = A !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word deriving Generic data F = F !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word !Word deriving Generic class B a where foo :: a -> Word {-# INLINE foo #-} default foo :: (Generic a, GB (Rep a)) => a -> Word foo !x = gfoo (from x) class GB f where gfoo :: (f a) -> Word instance GB x => GB (M1 D d (M1 C c x)) where {-# INLINE gfoo #-} gfoo (M1 (M1 x)) = gfoo x instance (GB a, GB b) => GB (a :*: b) where {-# INLINE gfoo #-} gfoo (a :*: b) = gfoo a + gfoo b instance GB (M1 S s (Rec0 Word)) where {-# INLINE gfoo #-} gfoo (M1 (K1 x)) = x instance B A instance B F main :: IO () main = return () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10408: The behavior of -ignore-dot-ghci and -ghci-script are weird
by GHC 20 Jul '15

20 Jul '15

#10408: The behavior of -ignore-dot-ghci and -ghci-script are weird -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Incorrect result Test Case: | at runtime Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- {{{ $ for i in `seq 10`; do echo "print $i" > /tmp/$i.ghci; done $ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci 2 1 0 $ ghc -e 0 -ghci-script /tmp/1.ghci -ghci-script /tmp/2.ghci -ignore-dot- ghci 0 }}} `-ghci-script` are executed in reverse order and are ignored when `-ignore-dot-ghci` is specified, while I expected that: * `-ghci-script` are executed in the order they are specified; * `-ignore-dot-ghci` only ignores the default .ghci files but still executes the scripts passed by `-ghci-script`. I would like to change the behavior to the expected ones. But in case there are users relying on the old behavior, then it might be necessary to introduce different flags. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #3744: Comparisons against minBound/maxBound not optimised for (Int|Word)(8|16|32)
by GHC 20 Jul '15

20 Jul '15

#3744: Comparisons against minBound/maxBound not optimised for (Int|Word)(8|16|32) -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) Comment: I just ran into this too. Perhaps the thing to do is to generate rules in PrelRules like {{{ narrow8IntOp x < 127 = True }}} etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3744#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0