- ghc-tickets - Haskell.org

[GHC] #8488: Annotations should not distinguish type and value
by GHC 01 Aug '15

01 Aug '15

#8488: Annotations should not distinguish type and value ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- In `HsDecls` we have {{{ data AnnDecl name = HsAnnotation (AnnProvenance name) (Located (HsExpr name)) data AnnProvenance name = ValueAnnProvenance name | TypeAnnProvenance name | ModuleAnnProvenance }}} And there's now a similar 3-way distinction in Template Haskell `Syntax`: {{{ data AnnTarget = ModuleAnnotation | TypeAnnotation Name | ValueAnnotation Name }}} But there's really no need to distinguish between `TypeAnnProvenance` and `ValueAnnProvenance` (and similarly in the TH vesrion) because the namespace on the `Name` makes that distinction. So the current story is redundant, and hence has silly case where you have a `ValueAnnProvenance` on a type constructor. Better to collapse the two. I'm making this a ticket so that people can comment. I hope that Gergely may be able to do it as part of his TH/annotation work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8387: View patterns + pattern bindings: finnicky about scoping
by GHC 01 Aug '15

01 Aug '15

#8387: View patterns + pattern bindings: finnicky about scoping ----------------------------+---------------------------------------------- Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Assume `{-# LANGUAGE ViewPatterns #-}`. This works: {{{ (id -> ()) = () }}} This also works: {{{ di :: a -> a di = \x -> x where (di -> ()) = () }}} But none of the following work: {{{ (di -> ()) = () -- Not in scope: di di :: a -> a di = \x -> x }}} {{{ di :: a -> a di = \x -> x (di -> ()) = () -- Not in scope: di }}} {{{ (di -> ()) = () -- Not in scope: di where di :: a -> a di = \x -> x }}} This looks like a bug to me. Is it? And is this in any way related to #4061? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10481: raise# should have an open kind in its return type
by GHC 01 Aug '15

01 Aug '15

#10481: raise# should have an open kind in its return type -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I noticed this while working on https://phabricator.haskell.org/D861. `error` has a wired-in type {{{#!hs error :: forall (a :: OpenKind). String -> a }}} and an implementation {{{#!hs error :: String -> a error s = raise# (errorCallException s) }}} But GHC will actually reject the definition of `error` if you check it against the wired-in type as `raise#` has a lifted kind. The only reason we can compile `base` is that open kinds cannot be expressed in Haskell source, so when GHC compiles `GHC.Err` it thinks `error` has a lifted kind, but for every other module it uses the wired-in type with an open kind. I'm marking this as low priority because I don't see how it could affect anyone outside of GHC developers, since open kinds aren't expressible in the source language. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10098: Refactor wild card renaming
by GHC 01 Aug '15

01 Aug '15

#10098: Refactor wild card renaming -------------------------------------+------------------------------------- Reporter: | Owner: thomasw thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #9922 Test Case: | Blocking: | Differential Revisions: Phab:D613 | -------------------------------------+------------------------------------- Imported from #9922, comment #5: --------------------- Austin: let's merge this to 7.10.1. Thomas: I'm not very happy with the way that wild-card error reporting is done. I think we discussed this before, but left it on one side until it was all working. Which it now is. What I suggest is this: Things I dislike: * I dislike the `checkParitalTypeSignature` and `checkNoPartialType` stuff in `RdrHsSyn`. The only checks that belong in `RdrHsSym` are ones that prevent you building a syntax tree at all. All other checks are best done later, when good error reporting is easier, and you can recover from errors. * I particularly hate the `RnTypes.extractWildcards` stuff. It's like a whole extra renaming pass over the type, changing `HsWildCardTy` to `HsNamedWildCardTy` with an `Exact` `RdrName` in it. Yuk! Here is a possible plan: * Remove all the checking from `RdrHsSyn`, unless we can't build a syntax tree without it. * Collapse `HsWildcardTy` and `HsNamedWildcardTy` into one, with a boolean (or a `Named`/`Anonymous` flag) to distinguish. * Provide a specialised version of `rnLHsType`, perhpas `rnLHsTypeWithWildCards`, that does the inital pass to find the named wildcards and bring them into scope. This version is called in the places where you can have a type with wildcards, namely * `TypeSig` * `ExprWithTySig` * `rnHsBndrSig` * `rnLHsTypeWithWildCards` can work like this: 1. Collect all the named wildcards, and bring them into scope. This is a simple, ''pure'' function. 2. Call `rnLHsType`. When `rnLHsType` finds an anonymous wildcard, just make up a fresh name, rather than looking it up. 3. Collect all the wildcards (named or anonymous) to get a `[Name]`; again a pure function 4. Return the renamed type and the wildcard names That makes three passes, but each is simple. In fact (1) and (4) could perhaps be the same function, with a boolean flag to say which wildcards to return. * All this means that when `rnLHsType` is called directly (not via `rnLHsTypeWithWildCards`) on a type like `_ -> Int`, it will succeed, generateing a fresh name for the `_`. That's fine. In `tc_hs_type` we will find it is not in scope, so we can say "Unexpected wildcard in type", and the enclosing location information will nail down the details. * There are, I think, three places where `HsWithBndrs` is used: `HsDecls.HsTyPats`, `HsDecls.RuleBndr`, `HsPat.SigPatIn`. In the latter two I think that wildcards should be legal; in the first not so. (Do you have tests for all three?) So the caller of `rnHsBndrSig` should check for empty wildcards in the cases where there shouldn't be any. I this this is just in type/data family patterns. I have not throught throught the extra-constraints wild card, but I think a similar plan should work. Does this make sense? Might you do it? (To HEAD, of course.) Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #6070: Fun with the demand analyser
by GHC 01 Aug '15

01 Aug '15

#6070: Fun with the demand analyser -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 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 thomie): * failure: None/Unknown => Runtime performance bug * milestone: 7.12.1 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6070#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10718: bitmap-0.0.2 SPECIALIZE pragma panic (GHC 7.10.1)
by GHC 01 Aug '15

01 Aug '15

#10718: bitmap-0.0.2 SPECIALIZE pragma panic (GHC 7.10.1) -------------------------------------+------------------------------------- Reporter: NCrashed | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Building with stack `bitmap-0.0.2` {{{ Configuring bitmap-0.0.2... Building bitmap-0.0.2... Preprocessing library bitmap-0.0.2... [ 1 of 10] Compiling Data.Bitmap.Internal ( Data/Bitmap/Internal.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.2.0/build/Data/Bitmap/Internal.o ) [ 2 of 10] Compiling Data.Bitmap.Base ( Data/Bitmap/Base.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.2.0/build/Data/Bitmap/Base.o ) [ 3 of 10] Compiling Data.Bitmap.IO ( Data/Bitmap/IO.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.2.0/build/Data/Bitmap/IO.o ) Data/Bitmap/IO.hs:1248:1: Warning: SPECIALISE pragma for non-overloaded function ‘myPlusPtr’ Data/Bitmap/IO.hs:1249:1: Warning: SPECIALISE pragma for non-overloaded function ‘myPlusPtr’ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Template variable unbound in rewrite rule $fPixelComponentFloat3_X2Rc [$fPixelComponentFloat3_X2Rc] [$fPixelComponentFloat3_X2Rc] [] [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7919: Heap corruption (segfault) from large 'let' expression
by GHC 01 Aug '15

01 Aug '15

#7919: Heap corruption (segfault) from large 'let' expression -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: rts/T7919 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1113 -------------------------------------+------------------------------------- Comment (by Simon Marlow <marlowsd@…>): In [changeset:"7cf87dfbf93f9839fa1e3b66a0233ac86f85a5f7/ghc" 7cf87dfb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7cf87dfbf93f9839fa1e3b66a0233ac86f85a5f7" Fix #7919 (again) Summary: The fix is a bit clunky, and is perhaps not the best fix, but I'm not sure how much work it would be to fix it the other way (see comments for more info). Test Plan: T7919 doesn't crash Reviewers: austin, rwbarton, ezyang, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1113 GHC Trac Issues: #7919 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7919#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5355: Link plugins against existing libHSghc
by GHC 01 Aug '15

01 Aug '15

#5355: Link plugins against existing libHSghc -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 5987 | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug * milestone: 7.12.1 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5355#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5463: SPECIALISE pragmas generated from Template Haskell are ignored
by GHC 01 Aug '15

01 Aug '15

#5463: SPECIALISE pragmas generated from Template Haskell are ignored -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 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 thomie): * failure: None/Unknown => Runtime performance bug * milestone: 7.12.1 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5463#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9230: Make -fwarn-tabs the default
by GHC 01 Aug '15

01 Aug '15

#9230: Make -fwarn-tabs the default -------------------------------------------+------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Tabs trip up an awful lot of Haskell beginners. Turning the warning on by default will likely save them a lot of grief. Any insane^h^h^h^h^h^hexperienced Haskellers who like tabs will have no trouble disabling the warning in their pragmas. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35