July 2015 - ghc-tickets

Re: [GHC] #8034: Missing ambiguity test for class methods
by GHC 30 Jul '15

30 Jul '15

#8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"58986c4953b045247cb09caa544981cccf14f242/ghc" 58986c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="58986c4953b045247cb09caa544981cccf14f242" Testsuite: add typecheck/should_fail/T8034 (#8034) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8034#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5333: Arrow command combinators and infixr cause the desugarer to fail
by GHC 30 Jul '15

30 Jul '15

#5333: Arrow command combinators and infixr cause the desugarer to fail -------------------------------------+------------------------------------- Reporter: peteg | Owner: ross Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.0.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"6880277381061593da2c2c19767ba508fb4045e3/ghc" 6880277/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6880277381061593da2c2c19767ba508fb4045e3" Testsuite: add arrows/should_compile/T5333 (#5333) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5333#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

30 Jul '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 -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => rts/T7919 * differential: => Phab:D1113 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7919#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7287: Primops in RULES generate warnings
by GHC 30 Jul '15

30 Jul '15

#7287: Primops in RULES generate warnings -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | simplCore/should_compile/T7287 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * owner: simonpj => * status: closed => new * resolution: fixed => Comment: Commit 2d88a531b7e4dbf4016dca4b1ba3b5dc34256cf4 ("Improve warnings for rules that might not fire") effectively cancels the fix in commit 419af69c1bea2cecce7b4bf58162cbfac81526f2 ("Give PrimOps a NOINLINE pragma, to suppress silly warnings from dsRule"). There is a comment in `testsuite/tests/simplCore/should_compile/T7287.hs` that indicates this is intentional. I'm reopening nevertheless, to be sure, since these two commits are so contradictory; maybe 419af69c1bea2cecce7b4bf58162cbfac81526f2 should be reverted? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7287#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5001: makeCorePair: arity missing
by GHC 30 Jul '15

30 Jul '15

#5001: makeCorePair: arity missing -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | deSugar/should_compile/T5001, | rename/should_fail/T5001b Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: deSugar/should_compile/T5001, rename/should_fail/T5001 => deSugar/should_compile/T5001, rename/should_fail/T5001b -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5001#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5001: makeCorePair: arity missing
by GHC 30 Jul '15

30 Jul '15

#5001: makeCorePair: arity missing -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | deSugar/should_compile/T5001, | rename/should_fail/T5001 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"b5097fe77f3d610db3eea8f659df927001bfcc10/ghc" b5097fe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5097fe77f3d610db3eea8f659df927001bfcc10" Testsuite: rename rename/should_fail/T5001 to T5001b (#5001) Test names should be unique. This fixes a framework failure. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5001#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10696: -fcpr-off doesn't disable CPR completely
by GHC 30 Jul '15

30 Jul '15

#10696: -fcpr-off doesn't disable CPR completely -------------------------------------+------------------------------------- Reporter: rwbarton | 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: | -------------------------------------+------------------------------------- `Demand.cprProdDmdType` produces nontrivial information even when `-fcpr- off` is specified. I think it's unintentional. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9772: Building documentation alone is broken
by GHC 30 Jul '15

30 Jul '15

#9772: Building documentation alone is broken -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment it seems that the only way to build documentation is to actually build all of GHC, which is nonsense. Methods of building documentation described in Building/Docs are broken: {{{ To build just the Haddock docs for a given library, do this: cd libraries/base make html stage=0 FAST=YES }}} That ends with errors. See `haddock_for_lib.log` attachement. {{{ To build a document on its own, for example the Users Guide, do this: cd docs/users_guide make html stage=0 FAST=YES substitute 'html' for 'pdf' or 'ps' to build other types of documentation. }}} That also ends with errors. See `users_guide.log` attachement. For above experiments I used the following lines in my `mk/build.mk` file: {{{ HADDOCK_DOCS = YES BUILD_DOCBOOK_HTML = YES BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO }}} Then I run `perl boot && ./configure`. I didn't run `make`, just the above instructions. My configure returns this: {{{ Configure completed successfully. Building GHC version : 7.9.20141105 Build platform : x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : x86_64-unknown-linux Bootstrapping using : /home/killy/.ghc-sandbox/bin/ghc which is version : 7.8.3 Using gcc : /usr/bin/gcc which is version : 4.5.1 Building a cross compiler : NO cpp : /usr/bin/gcc cpp-flags : -E -undef -traditional ld : /usr/bin/ld Happy : /home/killy/.cabal/bin/happy (1.19.4) Alex : /home/killy/.cabal/bin/alex (3.1.3) Perl : /usr/bin/perl dblatex : /usr/bin/dblatex xsltproc : /usr/bin/xsltproc Using LLVM tools llc : /usr/bin/llc opt : /usr/bin/opt HsColour : /home/killy/.cabal/bin/HsColour Building DocBook HTML documentation : NO Building DocBook PS documentation : YES Building DocBook PDF documentation : YES }}} I'm setting the milestone to 7.10.1. It's annoying to have this feature of the build system broken and it would be great to have this fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5001: makeCorePair: arity missing
by GHC 30 Jul '15

30 Jul '15

#5001: makeCorePair: arity missing -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | deSugar/should_compile/T5001, | rename/should_fail/T5001 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: deSugar/should_compile/T5001 => deSugar/should_compile/T5001, rename/should_fail/T5001 * resolution: => fixed Comment: OK, I've fixed this. `mono-traversable` is in error, and GHC properly reports it now: on line 514 of `MonoTraversable.hs` we have {{{ {-# INLINE ofoldMap #-} }}} but there is no corresponding method binding in that instance declaration. So that needs fixing in `mono-traversable`. Meanwhile I'll close the ticket. Thanks for the nice small test case. It's pretty harmless so no need to merge to 7.10. I added another test in `rename/should_fail/T5001`, not realising that we already have `deSugar/should_compile/T5001`. But that's fine, they don't conflict and test different things. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5001#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9600: Bad error message: Applicative is not a derivable class
by GHC 30 Jul '15

30 Jul '15

#9600: Bad error message: Applicative is not a derivable class -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- You have `GeneralizedNewtypeDeriving` on and use `deriving Applicative` with something that you cannot derive Applicative on, GHC correctly says `cannot eta-reduce the representation type enough`. If you don't have `GeneralizedNewtypeDeriving` on yet and deriving Applicative will work, GHC says something like "perhaps you want to enable GeneralizedNewtypeDeriving"? However, if you don't have `GeneralizedNewtypeDeriving` AND if GHC figures out that if you enable it, the next message will be `cannot eta-reduce the representation type enough`, then GHC will state the most unhelpful `Applicative is not a derivable class`, which suggests to me that '''in general''', Applicative is not derivable (which is wrong). rwbarton's suggestion: Suggest enabling `GeneralizedNewtypeDeriving` in any case and then let the user see why it cannot be derived. Some relevant #ghc chat: {{{ rwbarton, that's GND again rwbarton: I a ~ K a where K = ErrorT ImmError (ReaderT CliOptions (ReaderT Config IO)) is an instance of Applicative rwbarton: so it can coerce the instance for K to an instance for I nh2: so is it the error message that is the confusing part here? It suggests that "In general, Applicative is not derivable" nh2: I mean it as: Shouldn't it give an error message like "can't derive an Applicative instance in this case because ..."? rwbarton: well maybe it could add something like "Did you mean to use GeneralizedNewtypeDeriving?" rwbarton: oh I see what you mean, even if you turn that extension on it gives the same error message nh2: yes, because we already have such a message in some cases nh2: no, in this case I had really forgotten the extension. If I add it, I get the "cannot eta-reduce the representation type enough" error, but I haven't figured out why I get it in this case yet rwbarton: I wrote the condition above basically, "I a ~ K a where K = ... is an instance of Applicative" where ~ is the coercion/isomorphism introduced by the newtype rwbarton: if you can't write down K then you can't use GND because where would it get the instance? rwbarton: writing down K is eta reduction nh2: I'm wondering whether it doesn't suggest adding the extension because it already figured out I will not be able to eta-reduce? rwbarton: oh yeah, it seems so rwbarton: that seems a bit silly nh2: in this case, I think we should pimp the error message a bit nh2: (this is the thing I want to derive bwt: https://github.com /ganeti-github-testing/ganeti- test-1/blob/master/src/Ganeti/BasicTypes.hs#L147) nh2: what do you think would be the best error message to show in such a case? nh2: just suggest the GNTD suggestion regardless and let the user see afterwards that it cannot work? rwbarton: I would just have it always suggest GND ... yeah nh2: ok I file a ticket for that rwbarton: seems like more suggestions > fewer suggestions rwbarton: even if this is a weird second-order case where there are two errors }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5