June 2015 - ghc-tickets

[GHC] #10425: User's guide PDF version: Example with wrong indentation in Section 13.1.1.2
by GHC 02 Jun '15

02 Jun '15

#10425: User's guide PDF version: Example with wrong indentation in Section 13.1.1.2 -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the '''pdf''' version of User's Guide Version 7.10.1, the first example of "Section 13.1.1.2 Contex-free syntax" has the following wrong indentation: {{{#!hs main = do args <- getArgs if null args then return [] else do ps <- mapM process args mapM print ps }}} The HTML version is OK, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved
by GHC 02 Jun '15

02 Jun '15

#8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect | Blocking: warning at compile-time | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: infoneeded => new Comment: (How) is this supposed to work at all? I mean, if you want to be able to run a TH splice, you need to at some point generate code for the values used in the splice, right? Is the TH runner supposed to recompile the necessary module(s) with the bytecode generator? A minimal reproducer is simply {{{ -- A.hs {-# LANGUAGE TemplateHaskell #-} module A where a = [|3|] -- B.hs {-# LANGUAGE TemplateHaskell #-} module B where import A x = $(a) -- command: ghc -fno-code B }}} It might be possible to diagnose the situation and produce a better error message, but making this actually work seems solidly in feature request territory to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10461: Suggest UnliftedFFITypes when applicable
by GHC 02 Jun '15

02 Jun '15

#10461: Suggest UnliftedFFITypes when applicable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Here's an example bad error message: {{{ Serum.hs:5:1: Unacceptable result type in foreign declaration: ‘Word#’ cannot be marshalled in a foreign call When checking declaration: foreign import prim safe "static chenycopy" cheneycopy :: Any -> Word# }}} We should also add something like: {{{ To enable marshalling unlifted types, enable -XUnliftedFFITypes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10466: Bogus multiple-declaration error in GHCi + Template Haskell
by GHC 02 Jun '15

02 Jun '15

#10466: Bogus multiple-declaration error in GHCi + Template Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Try this (with ghc 7.8.3) {{{ th% ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 th $ ghc --interactive -XTemplateHaskell GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let x = True Prelude> let y = [d| x = 'c' |] <interactive>:3:13: Multiple declarations of ‘x’ Declared at: <interactive>:2:5 <interactive>:3:13 In the Template Haskell quotation [d| x = 'c' |] }}} This is obviously wrong, a failure of the name-shadwing code in `RnNames.extendGlobalRdrEnvRn`. I suspect that this afflicts 7.10 too, but I can't check that right now. Working on a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10466> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module
by GHC 02 Jun '15

02 Jun '15

#7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T7672 Blocked By: | Blocking: 10336 Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: T7672 => rename/should_compile/T7672 Comment: Despite all this clean up, the test for #7672 ''still'' does not work. Reason: in module A (comment:3), the data type `T` is in scope with two different provenances: * As `LocalDef` "T" * As `Imported` "B.T" But annoyingly, `Provenance` can't represent both; currently it's an either/or. Fixing this really means changing the `Provenance` data type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7672#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10423: Can't infer Monad n from (Monad m, m ~ n)
by GHC 02 Jun '15

02 Jun '15

#10423: Can't infer Monad n from (Monad m, m ~ n) -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This looks like a regression in GHC HEAD. {{{ Test/SmallCheck/Property.hs:187:10: Could not deduce (Monad n) arising from the superclasses of an instance declaration from the context: (Monad m, m ~ n) bound by the instance declaration at Test/SmallCheck/Property.hs:187:10-52 Possible fix: add (Monad n) to the context of the instance declaration In the instance declaration for ‘Testable n (Property m)’ }}} The code is here: https://github.com/feuerbach/smallcheck/blob/v1.1.1/Test/SmallCheck/Propert… Originally reported here: https://github.com/feuerbach/smallcheck/issues/28 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module
by GHC 02 Jun '15

02 Jun '15

#7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: T7672 valid program | Blocking: 10336 Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"9b73cb16485f331d9dc1f37826c6d503e24a5b0b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b73cb16485f331d9dc1f37826c6d503e24a5b0b" Refactor the GlobalRdrEnv, fixing #7672 This patch started innocently enough, by deleting a single call from rnImportDecl, namely let gbl_env = mkGlobalRdrEnv (filterOut from_this_mod gres) The 'filterOut' makes no sense, and was the cause of #7672. But that little loose end led to into a twisty maze of little passages, all alike, which has taken me an unreasonably long time to straighten out. Happily, I think the result is really much better. In particular: * INVARIANT 1 of the GlobalRdrEnv type was simply not true: we had multiple GlobalRdrElts in a list with the same gre_name field. This kludgily implmented one form of shadowing. * Meanwhile, extendGlobalRdrEnvRn implemented a second form of shadowing, by deleting stuff from the GlobalRdrEnv. * In turn, much of this shadowing stuff depended on the Names of the Ids bound in the GHCi InteractiveContext being Internal names, even though the TyCons and suchlike all had External Names. Very confusing. So I have made the following changes * I re-established INVARIANT 1 of GlobalRdrEnv. As a result some strange code in RdrName.pickGREs goes away. * RnNames.extendGlobalRdrEnvRn now makes one call to deal with shadowing, where necessary, and another to extend the environment. It deals separately with duplicate bindings. The very complicated RdrName.extendGlobalRdrEnv becomes much simpler; we need to export the shadowing function, now called RdrName.shadowNames; and we can nuke RdrName.findLocalDupsRdrEnv altogether. RdrName Note [GlobalRdrEnv shadowing] summarises the shadowing story * The Names of the Ids bound in the GHCi interactive context are now all External. See Note [Interactively-bound Ids in GHCi] in HscTypes. * Names for Ids created by the debugger are now made by IfaceEnv.newInteractiveBinder. This fixes a lurking bug which was that the debugger was using mkNewUniqueSupply 'I' to make uniques, which does NOT guarantee a fresh supply of uniques on successive calls. * Note [Template Haskell ambiguity] in RnEnv shows that one TH-related error is reported lazily (on occurrences) when it might be better reported when extending the environment. In some (but not all) cases this was done before; but now it's uniformly at occurrences. In some ways it'd be better to report when extending the environment, but it's a tiresome test and the error is rare, so I'm leaving it at the lookup site for now, with the above Note. * A small thing: RnNames.greAvail becomes RdrName.availFromGRE, where it joins the dual RdrName.gresFromAvail. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7672#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10473: Haskell Platform generic linux installer creates incorrect symlinks for /usr/local/man/man1 (and probably /usr/local/share/doc) when directory does not already exist
by GHC 02 Jun '15

02 Jun '15

#10473: Haskell Platform generic linux installer creates incorrect symlinks for /usr/local/man/man1 (and probably /usr/local/share/doc) when directory does not already exist -------------------------------------+------------------------------------- Reporter: brson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Following instructions here https://www.haskell.org/platform/linux.html for 'generic linux binaries'. After running activate-hs my /usr/local/man/man1 was a symlink to ghc.1 when it should be a directory *containing* ghc.1. This happens when the directory /usr/local/man/man1 does not already exist. Running activate-hs with --verbose --dryrun shows why: ln -sf usr/local/haskell/ghc-7.8.3-x86_64/bin/HsColour usr/local/haskell/ghc-7.8.3-x86_64/bin/activate-hs usr/local/haskell/ghc-7.8.3-x86_64/bin/alex usr/local/haskell/ghc-7.8.3-x86_64/bin/cabal usr/local/hask ell/ghc-7.8.3-x86_64/bin/ghc usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/ bin/ghci usr/local/haskell/ghc-7.8.3-x86_64/bin/ghci-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/haddock usr/local/haskell/ghc-7.8.3-x86_64/bin/haddock-ghc-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/happy usr/l ocal/haskell/ghc-7.8.3-x86_64/bin/hp2ps usr/local/haskell/ghc-7.8.3-x86_64/bin/hpc usr/local/haskell/ghc-7.8.3-x86_64/bin/hsc2hs usr/local/haskell/ghc-7.8.3-x86_64/bin/runghc usr/local/haskell/ghc-7.8.3-x86_64/bin /runghc-7.8.3 usr/local/haskell/ghc-7.8.3-x86_64/bin/runhaskell /usr/local/bin ln -sf usr/local/haskell/ghc-7.8.3-x86_64/share/man/man1/ghc.1 /usr/local/share/man/man1 ln -sf usr/local/haskell/ghc-7.8.3-x86_64/share/doc/ghc /usr/local/share/doc usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg register --verbose=0 --force usr/local/haskell/ghc-7.8.3-x86_64/etc/registrations/GLURaw-1.4.0.1 usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-pkg register --verbose=0 --force usr/local/haskell/ghc-7.8.3-x86_64/etc/registrations/GLUT-2.5.1.1 The second and third ln commands are incorrect. When there are multiple sources it treats the dest as a directory, but in these two instances there are only a single source so ln just creates man1 as a symlink. FWIW when this happens a subsequent install of Rust fails: https://github.com/rust-lang/rust-installer/issues/36. Rust v. Haskell: fight! ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #960: Lexical call site string
by GHC 02 Jun '15

02 Jun '15

#960: Lexical call site string -------------------------------------+------------------------------------- Reporter: paul@… | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: N/A Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by PaulJohnson): Replying to [comment:17 gridaphobe]: > Can we consider this issue fixed by the implicit call-stacks introduced in https://phabricator.haskell.org/D578? Yes, I believe you can. Thanks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/960#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #960: Lexical call site string
by GHC 02 Jun '15

02 Jun '15

#960: Lexical call site string -------------------------------------+------------------------------------- Reporter: paul@… | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: N/A Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gridaphobe): Can we consider this issue fixed by the implicit call-stacks introduced in https://phabricator.haskell.org/D578? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/960#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0