- ghc-tickets - Haskell.org

Re: [GHC] #4049: Support for ABI versioning of C libraries
by GHC 02 Dec '14

02 Dec '14

#4049: Support for ABI versioning of C libraries -------------------------------------+------------------------------------- Reporter: uzytkownik | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Package | Version: 6.12.2 system | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Build System => Package system -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4049#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8304: more lenient operator sections (RelaxedSections extension)
by GHC 02 Dec '14

02 Dec '14

#8304: more lenient operator sections (RelaxedSections extension) -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | 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: | -------------------------------------+------------------------------------- Some operator sections are rejected which could have some meaning. {{{ (a ++ b ++ ) could mean \x -> a ++ b ++ c (++ a ++) could mean \x y -> x ++ a ++ y }}} The attached quasiquoter implements this, but for various reasons it would be better if ghc supported this directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4052: Two sided sections
by GHC 02 Dec '14

02 Dec '14

#4052: Two sided sections -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.12.2 Component: Compiler | Keywords: section (Parser) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8304 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * component: Compiler => Compiler (Parser) * related: => #8304 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4052#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4096: New primops for indexing: index*OffAddrUsing# etc
by GHC 02 Dec '14

02 Dec '14

#4096: New primops for indexing: index*OffAddrUsing# etc -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.12.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown * failure: None/Unknown => Runtime performance bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4096#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9497: Silent typed holes
by GHC 02 Dec '14

02 Dec '14

#9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: typed holes, | Operating System: warnings | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have a UI feature request for -fwarn-typed-holes, currently there's two options: 1) typed holes are on (default) and GHC prints errors for types holes or 2) typed holes are off and GHC will print "not in scope" error and prematurely end compilation. When writing haskell, I frequently want to typecheck my code before it's completely implemented. Before I used undefined/error, which worked but I was always worried about accidentally forgetting an undefined somewhere. With typed holes this is no longer a problem, but unfortunately the warnings from typed holes are so verbose they drown out the other type errors. This makes typechecking during refactoring rather onerous. I propose adding a -fsilent-typed-holes and/or -ftreat-type-holes-as- undefined which enable typed holes, but silence any compile time warnings. It'd be nice if this flag treated holes as if "-fdefer-type-errors" was on, but ONLY for typed holes. This would let me compile the code and fix warnings, ignoring the holes while developing, while still assuring that, when I remove the flag and compile "for real" I get an error about typed holes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #5467: Template Haskell: support for Haddock comments
by GHC 02 Dec '14

02 Dec '14

#5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5467#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4347: Bug in unification of polymorphic and not-yet-polymorphic type
by GHC 02 Dec '14

02 Dec '14

#4347: Bug in unification of polymorphic and not-yet-polymorphic type -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.1 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dolio): To be honest, I'd be fine with closing this ticket. I filed it right around the 6 -> 7 cutover, and evidently thought that the new type checker was still supposed to handle impredicative instantiation. But, the truth is, I think, that if the new algorithm does handle certain impredicative cases, it's more a happy accident than a design principle. So my const example happened to work, but id didn't at the time. I interpreted that as a bug with id rather than being happy that it worked at all for const. I'll leave it to the implementors to decide. If the id example works in 7.10, that's handy. But I've long since stopped considering 'regressions' in impredicative instantiation relative to 6.x actual regressions. It's merely the result a different set of tradeoffs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4347#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9833: GHCi suggestion for instance signature (InstanceSigs) is wrong
by GHC 02 Dec '14

02 Dec '14

#9833: GHCi suggestion for instance signature (InstanceSigs) is wrong -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- With `InstanceSigs` and `PolyKinds` enabled and the following type with kind `ĸ -> *`: {{{#!hs data NullableInterp a = NullI Bool }}} I want to make it an instance of `Alternative` and I decide to supply a signature for `empty`: {{{#!hs instance Alternative NullableInterp where empty :: NullableInterp a empty = undefined (<|>) = undefined }}} but GHCi complains with the following error: {{{#!hs % ghci -ignore-dot-ghci error.hs GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( error.hs, interpreted ) error.hs:14:12: Method signature does not match class; it should be empty :: forall a. NullableInterp a In the instance declaration for ‘Alternative NullableInterp’ Failed, modules loaded: none. Prelude> }}} Trying GHCi's suggestion (with appropriate extensions) doesn't help and I have to write `empty :: NullableInterp (a :: *)` for it to work. I'm not sure which behaviour is the right one but either it should have compiled or GHCi's suggestion should be `empty :: forall a. NullableInterp (a :: *)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7908: InstanceSigs suggestion not accepted
by GHC 02 Dec '14

02 Dec '14

#7908: InstanceSigs suggestion not accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"c34ef467429771edf0b2b18c05994c461c82df38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c34ef467429771edf0b2b18c05994c461c82df38" Test Trac #7908 Fixed by e6a2050ebb6da316aecec66a6795715fbab355ca along with #9582, #9833 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7908#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9480: Segfault in GHC API code using Shelly
by GHC 01 Dec '14

01 Dec '14

#9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A segfault occurs when using the GHC API with Shelly. I do not know why. Here is a code snippet that triggers it: {{{#!hs import GHC import GHC.Paths ( libdir ) import DynFlags main = runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags $ dflags { hscTarget = HscInterpreted, ghcLink = LinkInMemory } imports <- mapM parseImportDecl ["import Shelly", "import Prelude"] setContext $ map IIDecl imports runStmt "shelly undefined" RunToCompletion }}} Note that on Mac OS X, this has no output whatsoever. The segfault occurs on Ubuntu 14.04, with `uname -a` outputting the following: {{{ Linux yed 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux }}} I cannot find any way to get this to work and have no idea what's up with this or why shelly triggers it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9480> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11