October 2015 - ghc-tickets

Re: [GHC] #1831: reify never provides the declaration of variables
by GHC 05 Oct '15

05 Oct '15

#1831: reify never provides the declaration of variables -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer Comment: It strikes me that this wouldn't actually be terribly hard to do. `INLINEABLE` identifiers have their unfoldings available. These unfoldings are expressed in Core. But it shouldn't be very hard to translate Core to the TH AST. Just looking at unfoldings would mean that this feature wouldn't work for identifiers declared in the same module as the `reify` but ''not'' declared `INLINEABLE` (or something that implies `INLINEABLE`). This would be disappointing to some people, I'm sure, but we can iteratively get better with this feature. I'll say this is appropriate for an ambitious newcomer. I don't think you'll have to know a ton about the internals of GHC, but it's way more than a few lines to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1831#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10932: Pattern synonyms and view pattern arguments
by GHC 05 Oct '15

05 Oct '15

#10932: Pattern synonyms and view pattern arguments -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- In my code, I had a few complicated patterns involving view patterns that depended on local arguments, i.e. {{{ foo env (someView env -> Just x) = ... }}} I was hoping to be able to use PatternSynonyms to abstract and simplify this: {{{ pattern Pat env x <- (someView env -> Just x) foo env (Pat env x) = ... }}} but it says `Not in scope: env`. It would be nice if I could use pattern synonyms here as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 05 Oct '15

05 Oct '15

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 | Phab:D1310 -------------------------------------+------------------------------------- Comment (by Phyx-): I can make the changes that's no problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 05 Oct '15

05 Oct '15

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 | Phab:D1310 -------------------------------------+------------------------------------- Comment (by archblob): Hello Phyx, Yes it covers it and I see that you have made it so that the old test still runs on linux. I'm of the opinion that we should also make the linux test against your custom lib so that we don't have any headaches in the future. I can do it, or you can do it after your patch lands, whatever is best for you, just let me know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5289: Can't use ghci with a library linked against libstdc++
by GHC 05 Oct '15

05 Oct '15

#5289: Can't use ghci with a library linked against libstdc++ -------------------------------+---------------------------------------- Reporter: bos | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1310 -------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D1310 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5289#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5289: Can't use ghci with a library linked against libstdc++
by GHC 05 Oct '15

05 Oct '15

#5289: Can't use ghci with a library linked against libstdc++ -------------------------------+---------------------------------------- Reporter: bos | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------+---------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5289#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1883: GHC can't find library using "short" name
by GHC 05 Oct '15

05 Oct '15

#1883: GHC can't find library using "short" name -------------------------------------+------------------------------------- Reporter: m4dc4p | Owner: Phyx- Type: bug | Status: patch Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: link library | windows Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #2283 #3242 | Differential Rev(s): Phab:D1310 #1883 #7097 | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D1310 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1883#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files
by GHC 05 Oct '15

05 Oct '15

#1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 | Phab:D1310 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: Phab:D194 => Phab:D194 Phab:D1310 Comment: Hi archblob, This should be covered under Phab:D1310 that I submitted to correct another issue. See test 'ghci_short_name'. Let me know if this is sufficient for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1407#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 04 Oct '15

04 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Thanks erikd! Applied to `ghc-7.10` as e22d7dc434b64709a4b19b11f2e0a41676c04035. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10071: Implement warnings for class-method overriding
by GHC 04 Oct '15

04 Oct '15

#10071: Implement warnings for class-method overriding -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: AMP | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #8004, #4384 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This would aid long-term transitions like phasing out `Monad(return)` (in the spirit of #4834): With the AMP, `Monad(return)` being a class method becomes an historic artifact. The ideal long-term situation would rather be to have `return` become a top-level definition (i.e. outside the `Monad`-class), generalised to `Applicative` just aliasing `Applicative(pure)`, i.e. {{{#!hs return :: Applicative f => a -> f a return = pure }}} This may be beneficial for things like ApplicativeDo which otherwise would require a `return` to be handled is if it was `pure` in order to weaken the type-constraint in an `do`-expression like e.g. {{{#!hs do { x <- f; return (fst x) } }}} Right now, we can attach a `DEPRECATE`-pragma to the `return`-class- method. That however would trigger warnings on ''all'' uses of `return`, rather than only when using `return` in a context that requires it to be a class-method (like overriding `return` in instance definitions, or importing/exporting it via the explicit `Monad(return)`-syntax) Instead we need a way to warn about such uses of `return` which assume it to be a class-method, in order to phase out such uses. NB: This will probably require additional discussions, but we shouldn't wait too long, if we want to integrate the AMP into a future Haskell Report (for which we should try to clean up historic warts such as `Monad(return)` if feasable). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15