- ghc-tickets - Haskell.org

Re: [GHC] #5442: ghc-pkg unregister --user/--global/--package-conf not normative
by GHC 21 Jul '14

21 Jul '14

#5442: ghc-pkg unregister --user/--global/--package-conf not normative -------------------------------------+------------------------------------- Reporter: guest | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.2.1 Resolution: | Keywords: Differential Revisions: Phab:D84 | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D84 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5442#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5442: ghc-pkg unregister --user/--global/--package-conf not normative
by GHC 21 Jul '14

21 Jul '14

#5442: ghc-pkg unregister --user/--global/--package-conf not normative -------------------------------------+------------------------------------- Reporter: guest | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.2.1 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: bgamari => ezyang Comment: OK, I can confirm that there is something fishy going on here. Here is the matrix of behaviors that ghc-pkg implements right now: * If P is in the user and global, {{{unregister --user}}} removes user, {{{unregister --global}}} removes **USER**, {{{unregister}}} removes user * If P is in the user but not global, {{{unregister --user}}} removes user, {{{unregister --global}}} removes **USER**, {{{unregister}}} removes user * If P is in the global but not user, {{{unregister --user}}} removes **GLOBAL**, {{{unregister --global}}} removes global, {{{unregister}}} removes global This seems clearly wrong. The bug seems to me that ghc-pkg calculates the database to modify fine, but then ignores it in {{{modifyPackage}}}, always using the full database stack rather than the database it calculated to use. My suggested fix is to switch unregister to use the flag package stack, since it is implicitly a read, and then a delete. But I don't know if there is any existing tooling that would be broken by this fix. I have a patch and test-cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5442#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9092: ghc: panic! (the 'impossible' happened)
by GHC 21 Jul '14

21 Jul '14

#9092: ghc: panic! (the 'impossible' happened) -----------------------------------+--------------------------------------- Reporter: alex404 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: panic | Operating System: Linux impossible | Type of failure: Compile-time crash Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I'm not sure *why* this is happening, but I know where. The code for this library is available here: http://hub.darcs.net/alex404/hsl-random So as is, I can run the script called multivariate and get the expected results, but when I try to compile I get ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): attempt to prod-split usage call demand C(C1(U(U,U,U,U,U,U))) If at line 317 in Scientific.Random.Distributions.hs, I replace the statement sgma = ... with sgma = undefined, the code will compile, though obviously it cannot be used. If I transform the code in other ways which are meant to preserve the results, I can get it to compile, but then the script hangs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4213: LLVM: Add support for TNTC to LLVM compiler suite
by GHC 21 Jul '14

21 Jul '14

#4213: LLVM: Add support for TNTC to LLVM compiler suite -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 6.13 Component: Compiler | Keywords: (LLVM) | Operating System: Unknown/Multiple Resolution: | Type of failure: None/Unknown Differential Revisions: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: 9142 | Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): After reading Rafael's suggestion more closely it's not at all clear that this will do what we want (namely, it's unclear how one would actually attach code to the defined symbol). I've asked for further clarification although I suspect we'll need need to use LLVM's `symbol_offset` support to make this work. Hopefully we'll be able to get them to amend the semantics of this attribute to be more convenient for our purposes before 3.5 is cut. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4213#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9324: GHCi permission checks should ignore root user
by GHC 21 Jul '14

21 Jul '14

#9324: GHCi permission checks should ignore root user -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: POSIX | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- As a security precaution, GHCi helpfully refuses to run a `.ghci` file if it is owned by another user. But if the that other user is root, then arguably GHCi should not refuse to interpret the file, because if root really was malicious, then the user would be having a bad day anyways. This means that .ghci files installed in a global location, say under `/usr/local/`, can then be read. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9317: Add PolyKinds extension to Data.Monoid
by GHC 21 Jul '14

21 Jul '14

#9317: Add PolyKinds extension to Data.Monoid -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Easy (less Blocking: | than 1 hour) | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: <http://www.haskell.org/pipermail/libraries/2014-July/023261.html>. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o
by GHC 21 Jul '14

21 Jul '14

#7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.6.1 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: x86_64 | failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"021b7978d14799bae779907faf7490cfd21b3f46/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="021b7978d14799bae779907faf7490cfd21b3f46" driver: use absolute paths in ld scripts (#7452) Patch contributed by slowmo. Signed-off-by: Austin Seipp <austin(a)well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7452#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM
by GHC 21 Jul '14

21 Jul '14

#6016: On Windows, runhaskell hits an error on UTF-8 files with a BOM -------------------------------------+------------------------------------- Reporter: vsajip | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Keywords: BOM Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #1744 | -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple * related: => #1744 Old description: > The file > > {{{ > #!/usr/bin/env runhaskell > main = putStrLn "Hello, world!" > }}} > works on Windows as expected: > > {{{ > C:\Temp>runhaskell hello.hs > Hello, world! > }}} > However, if the file is saved as UTF-8 with a BOM (Windows Notepad, for > example, sometimes adds this BOM to files), an error occurs: > > {{{ > C:\Temp>runhaskell hello2.hs > > hello2.hs:1:1: parse error on input `#!/' > }}} > > I'm using the Haskell Platform 2011.4.0.0. > > I believe that runhaskell/runghc should handle the presence of a BOM > correctly; some Windows programs insert a BOM unbeknownst to the user. > > This behaviour was observed on Windows XP (32-bit) and Windows 7 (32-bit > and 64-bit). New description: The file {{{ #!/usr/bin/env runhaskell main = putStrLn "Hello, world!" }}} works as expected: {{{ C:\Temp>runhaskell hello.hs Hello, world! }}} However, if the file is saved as UTF-8 with a BOM (Windows Notepad, for example, sometimes adds this BOM to files), an error occurs: {{{ C:\Temp>runhaskell hello2.hs hello2.hs:1:1: parse error on input `#!/' }}} I'm using the Haskell Platform 2011.4.0.0. I believe that runhaskell/runghc should handle the presence of a BOM correctly; some Windows programs insert a BOM unbeknownst to the user. This behaviour was observed on Windows XP (32-bit) and Windows 7 (32-bit and 64-bit). -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6016#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5401: LANGUAGE pragma parser nit
by GHC 21 Jul '14

21 Jul '14

#5401: LANGUAGE pragma parser nit -------------------------------------+------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.0.3 (Parser) | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > A language pragma like > {{{ > {-# LANGUAGE > TypeOperators, > FlexibleContexts #-} > }}} > parses just fine but > {{{ > {-# LANGUAGE > TypeOperators, > FlexibleContexts > #-} > }}} > doesn't, saying: > {{{ > Cannot parse LANGUAGE pragma > Expecting comma-separated list of language options, > each starting with a capital letter > }}} > An OPTIONS pragma, on the other hand, accepts either format without > complaint. New description: Language pragmas like {{{ {-# LANGUAGE TypeOperators, FlexibleContexts #-} }}} or {{{ {-# LANGUAGE TypeOperators, FlexibleContexts #-} }}} parse just fine but {{{ {-# LANGUAGE TypeOperators, FlexibleContexts #-} }}} doesn't (note the missing spaces before the closing `#-}`), saying: {{{ Cannot parse LANGUAGE pragma Expecting comma-separated list of language options, each starting with a capital letter }}} An OPTIONS_GHC pragma, on the other hand, accepts either format without complaint. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5401#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7452: [GNU gold] ld: error: cannot find [...]/Types__1.o
by GHC 20 Jul '14

20 Jul '14

#7452: [GNU gold] ld: error: cannot find [...]/Types__1.o -------------------------------------+------------------------------------- Reporter: mrothe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.6.1 System | Keywords: Resolution: | Operating System: Linux Differential Revisions: | Type of failure: Building GHC Architecture: x86_64 | failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7452#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0