September 2014 - ghc-tickets

[GHC] #9544: No error message in explicit import containing unused and undefined constructor (Regression)
by GHC 03 Sep '14

03 Sep '14

#9544: No error message in explicit import containing unused and undefined constructor (Regression) -------------------------------------+------------------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Helper file: {{{#!hs module A where data X = Foo }}} Reproduction: {{{#!hs module B where import A (X (X)) f :: X f = undefined }}} Result (GHC 7.8.3): {{{ $ ghc -Wall B.hs [1 of 2] Compiling A ( A.hs, nothing ) [2 of 2] Compiling B ( B.hs, nothing ) $ }}} Result (GHC 7.6.3): {{{ $ ghc -Wall B.hs [1 of 2] Compiling A ( A.hs, nothing ) [2 of 2] Compiling B ( B.hs, nothing ) B.hs:3:11: Module `A' does not export `X(X)' $ }}} I tested other combinations and this regression seems to only occur when using an explicit import list and specifying an undefined constructor with the same name as the type. If you try to use the undefined constructor you will get an error at the use site instead of the import site. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9519: Add a way to mask thread preemption via fired timer for a computation
by GHC 03 Sep '14

03 Sep '14

#9519: Add a way to mask thread preemption via fired timer for a computation -------------------------------------+------------------------------------- Reporter: abbradar | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This follows haskell-cafe discussion [http://www.haskell.org/pipermail /haskell-cafe/2014-August/115656.html]. In brief: some C libraries (for example, SDL) use thread-local variables for error state of the last call. Without some way to temporarily mask timer-based lightweight thread preemption on one OS thread, there is no safe way to use such libraries and retrieve errors aside from using a global MVar (which will block all calls, not just ones on the same OS thread). For "errno" variable from C standard library, this is handled explicitly in RTS by saving its state for each lightweight thread. So the proposal is: add new prims (something in lines of "maskPreemption#", "unmaskPreemption#" and "getPreemptionState#") which will make a computation not preemptable via fired timer and temporarily attached to one OS thread, and corresponding functions in Control.Concurrent. They should be able to be used together with "Control.Exception.mask" to also block async exceptions, if this is needed. (I'm sorry if I've misunderstood something or did something the wrong way; I don't know the internal workings of RTS and this is my first GHC bug report). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9519> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 03 Sep '14

03 Sep '14

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): I agree that byte-identical build results might be useful (though difficult), I question whether you need it for ccache. ccache doesn't need to compare build results, only build *inputs*; when the inputs are the same we can re-use the previous output. It doesn't matter whether repeating the build would produce the exact same output, only that it is valid to re-use the previous output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8052: make ghci look for the files made by -dynamic-too
by GHC 03 Sep '14

03 Sep '14

#8052: make ghci look for the files made by -dynamic-too -----------------------------------+--------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- If I compile with `-dynamic-too`, ghci still re-interprets the source code instead of finding the `Test.dyn_o` file. {{{ $ inplace/bin/ghc-stage2 -O1 -dynamic-too -c Test.hs $ inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.7.20130710: 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 Test ( Test.hs, interpreted ) Ok, modules loaded: Test. *Test> }}} I'm guessing that ghci sees the `.o` file isn't suitable for dynamic loading and then falls-back to the interpreter without first checking for the `.dyn_o` file. ghci loads `Test.o` as expected if I instead compile with `-dynamic`. I'm on OS X 64-bit, if that might matter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9542: GHC-IO-Handle-Text.hputStr' and writeBlocks look like they need refactoring
by GHC 02 Sep '14

02 Sep '14

#9542: GHC-IO-Handle-Text.hputStr' and writeBlocks look like they need refactoring -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The boundary between `writeBlocks` and `hPutStr'` looks badly drawn, with pieces of buffering type on either side. I would also speculate that one or more CRLF-related helper functions may be in order. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9531: Implement Prelude.Word Proposal
by GHC 02 Sep '14

02 Sep '14

#9531: Implement Prelude.Word Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: Prelude | 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: -------------------------------------+------------------------------------- ''(this text is a placeholder and will be replaced shortly)'' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #6077: Respect XDG_CONFIG_HOME
by GHC 02 Sep '14

02 Sep '14

#6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.4.1 Component: None | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Other | Blocked By: 5966 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by god): Supporting XDG spec in the standard library is one thing but actually converting the ghc itself to use it is another. Those tasks are certainly related but I think it's worth to keep the corresponding bugs separate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6077#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6077: Respect XDG_CONFIG_HOME
by GHC 02 Sep '14

02 Sep '14

#6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.4.1 Component: None | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Other | Blocked By: 5966 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by god): * status: closed => new * resolution: duplicate => * blockedby: => 5966 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6077#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #367: Infinite loops can hang Concurrent Haskell
by GHC 02 Sep '14

02 Sep '14

#367: Infinite loops can hang Concurrent Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler Operating System: | allocation Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: concurrent/should_run/T367, | concurrent/should_run/T367_letnoescape| Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jberryman): Replying to [comment:40 simonmar]: > Yes, this is an instance of the bug. Does it work with `-fno-omit- yields`? Okay, thank you. Yes `-fno-omit-yields` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/367#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 02 Sep '14

02 Sep '14

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): @simonmar: Then I shall leave this ticket to issues concerning (1), and create a separate one for byte-identical compilation. Why would you want byte-identical compilation (or, how Debian calls it, "reproducible builds")? There are a few reasons (3 is the key point for me right now): 1. Distributions want it (see https://wiki.debian.org/ReproducibleBuilds#Why_do_we_want_reproducible_buil…) 2. It allows users of open source projects (e.g. Tor, TrueCrypt had famous efforts in this direction) to verify that the binary they downloaded really is built from the unmodified source 3. It gives recompilation avoidance in build systems outside of GHC. If the binary you just produced is byte-identical to what was already there, you can stop (e.g. don't need to run tests in CI etc.). And finally, a more-belief-than-evidence-supported point: 5. It will improve binary distributions of cabal packages and similar things. For example, I would like to build a Haskell equivalent to `ccache`, and having byte-identical output for the same input would make that much easier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0