August 2015 - ghc-tickets

[GHC] #10586: GHC 7.10.1 panic due to wildcard in data family instance
by GHC 03 Aug '15

03 Aug '15

#10586: GHC 7.10.1 panic due to wildcard in data family instance -------------------------------------+------------------------------------- Reporter: | Owner: WrenThornton | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following simple program causes GHC 7.10.1 (for x86_64-apple-darwin) to panic (rnHsTyKi HsWildcardTy): {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, PolyKinds #-} data MyKind = A | B data family Sing (a :: k) data instance Sing (_ :: MyKind) where SingA :: Sing A SingB :: Sing B }}} Because data family instances must be fully saturated, we must give some name to the parameter; but because our instance is a GADT, the name of that parameter is meaningless, so using the wildcard makes complete sense here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #3699: Wildcards in type functions
by GHC 03 Aug '15

03 Aug '15

#3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: msosn MartijnVanSteenbergen | Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.4 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1092 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"d9d2102ea7f6da1bc3a69fa469b89ea843cb8b02/ghc" d9d2102e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d9d2102ea7f6da1bc3a69fa469b89ea843cb8b02" Support wild cards in data/type family instances Handle anonymous wild cards in type or data family instance declarations like unnamed type variables. For instance (pun intented): type family F (a :: *) (b :: *) :: * type instance F Int _ = Int Is now the same as: type family F (a :: *) (b :: *) :: * type instance F Int x = Int Note that unlike wild cards in partial type signatures, no errors (or warnings with -XPartialTypeSignatures) are generated for these wild cards, as there is nothing interesting to report to the user, i.e. the inferred kind. Only anonymous wild cards are supported here, named and extra-constraints wild card are not. Test Plan: pass new tests Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1092 GHC Trac Issues: #3699, #10586 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3699#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10134: Pattern Matching Causes Infinite Type Error
by GHC 03 Aug '15

03 Aug '15

#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Howsagoin, This is a report about ghci (7.8.4) with CLaSH 0.4.1 I have a collection of modules that show an odd error. I don't want to send them to the list but I can send them to the developers if they think the described behaviour is definitely an error, which I suspect it is. When I write: > (a,b) = expression I get a type error about an occurs check: cannot construct infinite type: t0 ~ (t0 + 1) -1. The error message doesn't mention t0. However, when I leave out the pattern matching on the tuple and write > var = expression > a = fst var > b = snd var where var is a fresh variable, everything is fine. This is odd, because all I did was stripping off the pattern matching. To make sure, I also tried > var = expression > (a,b) = var This also gave the same type checking error. If there's anybody willing to have a look at this, please feel free to contact me by email. If you think I should produce a small example, also please let me know, but please note that it already took me several hours before I found that leaving out the pattern matching solved the problem:-( TIA for your time. Marc van Dongen dongen(a)cs.ucc.ie -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #10722: GHC generates wrong unused type argument warning(ScopedTypeVariables related)
by GHC 03 Aug '15

03 Aug '15

#10722: GHC generates wrong unused type argument warning(ScopedTypeVariables related) -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | 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 Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE KindSignatures, ScopedTypeVariables #-} {-# OPTIONS_GHC -Wall #-} module Main where import Data.Proxy class Blah (a :: * -> *) where f :: a b -> b instance forall b . Blah [] where f a = let (_ :: Proxy b) = undefined in head a main :: IO () main = return () }}} When I run this using GHC 7.10.1 and GHC HEAD, I'm getting this warnings: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:12:17: warning: Unused quantified type variable ‘b’ In the type ‘forall b. Blah []’ In an instance declaration Main.hs:13:13: warning: This pattern-binding binds no variables: (_ :: Proxy b) = undefined Linking Main ... }}} First warning is wrong. `b` is used, and this program doesn't compile if I remove that `b`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10722> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #3306: Improve syntax for GADT + records
by GHC 03 Aug '15

03 Aug '15

#3306: Improve syntax for GADT + records -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by skvadrik): * failure: => None/Unknown Comment: 6 years later: removed deprecated syntax for GADT constuctors. This allows to get rid of 2 reduce/reduce conflicts in parser. Conflicting productions were: {{{ gadt_constr -> con_list '::' sigtype gadt_constr -> oqtycon '{' fielddecls '}' '::' sigtype }}} Recursive inlining of con_list and oqtycon helped reveal the conflict: {{{ gadt_constr -> '(' CONSYM ')' '::' sigtype gadt_constr -> '(' CONSYM ')' '{' fielddecls '}' '::' sigtype }}} between two types of GADT constructors (second form stands for deprecated syntax). However, old syntax allowed `oqtycon` in constructor names, while new syntax allows `con` (which is not the same). There are therefore some constructor names that cannot be expressed in terms of new syntax (e.g. `(*)`). Note that ordinary data constructors are parsed in a different way than GADTs: types and names are mixed, so names have to be parsed as types and then converted to names. In GADTs constructor names and types are separated by `::`, so names can be parsed as just names and not as types. This results in a difference in the set of names allowed in GADT and ordinary constructors. See `Note [Parsing data constructors is hard]` and `Note [Difference in parsing GADT and data constructors]` Differential Revision: https://phabricator.haskell.org/D1118 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3306#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 03 Aug '15

03 Aug '15

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, do rebase `wip/nested-cpr` on master, do a like-for-like `nofib` comparison. I'd quite like to see this land. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64
by GHC 03 Aug '15

03 Aug '15

#10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 -------------------------------------+------------------------------------- Reporter: stengel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effectively marks the area with the saved registers as reusable. Later, the CPU registers are restored from this "free" area. This ordering happens to work by accident on operating systems that strictly adhere to the System V ABI, because any interrupt/signal delivery is guaranteed to leave the first 128 bytes past the stack pointer untouched (red zone). On other systems this might result in corrupted CPU registers if an interruption happens just after restoring the stack pointer. The red zone is usually only used by small leaf functions to avoid updates to the stack pointer and exploiting it doesn't give us any advantage in this case. The attached patch reorders the register access, so that the stack pointer is restored last. It's also shorter by one instruction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10543: MacOS: validate fails on \u
by GHC 03 Aug '15

03 Aug '15

#10543: MacOS: validate fails on \u -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: MacOS X Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Running validate on MacOS fails with this error (due to `-Werror`): {{{ libraries/Cabal/Cabal/Distribution/Simple/BuildTarget.hs:392:24: error: \u used with no following hex digits; treating as '\' followed by identifier [-Werror,-Wunicode] matchBuildTarget pkg = \utarget fexists -> ^ 1 error generated. make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 }}} I am using ghc from homebrew to bootstrap on OS X 10.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10729: Type inference in GADT pattern matches
by GHC 03 Aug '15

03 Aug '15

#10729: Type inference in GADT pattern matches -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When pattern matching against GADT constructors, GHC seems to have issues with inferring the type of the resulting expression. Minimal example: Assume the datatype: {{{ data D a where D :: D () }}} A simple function that pattern matches on it: {{{ a D = () }}} It is expected to have type `D a -> ()` (Note: not `D () -> ()`, existence of a `D` should ensure `()`, not the type signature), but instead it errors: {{{ error: Couldn't match expected type ‘t’ with actual type ‘()’ ‘t’ is untouchable inside the constraints: t1 ~ () bound by a pattern with constructor: D :: D (), in an equation for ‘a’ ‘t’ is a rigid type variable bound by the inferred type of a :: D t1 -> t }}} Note that the error goes away when we annotate the type of the function: {{{ b :: D a -> () -- no error b D = () }}} Or if we supply another branch that clarifies the type: {{{ c D = () -- no error c _ = () }}} But it reappears if the other branch doesn't provide anything to infer from: {{{ d D = () -- error d _ = undefined }}} The same issue happens in `case`: {{{ e x = case x of D -> () -- error }}} But only when the value being matched comes from outside: {{{ f = case D of D -> () -- no error }}} This behavior is reprooducible and identical in 7.8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 02 Aug '15

02 Aug '15

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by amosrobinson): Hmm. So I thought in this case, the is_too_recursive check should stop specialisation after a few runs. The counting of recursive constructors is only going down through applications though: I wonder whether it needs to handle lets, cases, etc? https://github.com/ghc/ghc/blob/master/compiler/specialise/SpecConstr.hs#L1… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0