- ghc-tickets - Haskell.org

[GHC] #8150: Foreign export requires redundant type signature
by GHC 20 Mar '15

20 Mar '15

#8150: Foreign export requires redundant type signature -------------------------+------------------------------------------------- Reporter: | Owner: evincarofautumn | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- With a source file such as: {{{ module FFITest where foreign export ccall "function" function :: IO () function :: IO () function = putStrLn "Hello, world!" }}} The second `function :: IO ()` signature is required to satisfy `-fwarn- missing-signatures`, even though a signature is already present in the `foreign export` declaration, and the types are required to be the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10171: runghc has problem when the argument list is too big
by GHC 20 Mar '15

20 Mar '15

#10171: runghc has problem when the argument list is too big -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: POSIX Architecture: | Type of failure: Runtime crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The way `runghc` works is by calling `ghc` with some extra arguments. These extra arguments cause the `argv` passed to `ghc` to be larger than the original one. This can cause the size of `argv` to exceed the maximum allowed. This might seem like a minor issue, but it can confuse several unix tools that rely on exact calculations on the size of `argv`, such as `xargs` or `find` with the `-exec` option. To demonstrate the problem, consider the following the program (call it `print_size.hs`): {{{#!hs import System.Environment import System.Posix main = getArgs >>= mapM_ printSize where printSize file = do st <- getSymbolicLinkStatus file putStrLn $ show (fileSize st) ++ " " ++ file }}} The program interpreters its `argv` as a list of files and prints their sizes. Now suppose that you want to run the program without compiling it (i.e. by interpreting it) on a specific set files, as returned by `find`. For example, consider something like that: {{{ find / -exec runhaskell print_size.hs {} + }}} If you run this, you will get the following error (multiple times): {{{ runghc: /usr/bin/ghc: rawSystem: runInteractiveProcess: exec: resource exhausted (Argument list too long) }}} The problem here is that the `-exec` option of `find`, when used with the `+` switch, works as follows: it starts collecting the list of found files and just before the list exceeds the maximum allowed size for `argv` it runs the specified program on that list (it works this way in order to minimize the number of times the program is ran). Of course this is problematic because `runghc` will then increase the size of `argv` and because of that the call to `ghc` might fail. The same thing happens if you try to run the following as well: {{{ find / -print0 | xargs -0 runhaskell print_size.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10011: The Data instance for Ratio violates internal invariants.
by GHC 20 Mar '15

20 Mar '15

#10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1-rc1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I found this when Simon was cleaning up unused dependencies in {{{ https://phabricator.haskell.org/rGHCc409b6f30373535b6eed92e55d4695688d32be9… }}} The Data instance for Ratio just uses the raw `(:%)` constructor and doesn't check that the result is reduced to normal form. It strikes me that the fix is to add back the Integral constraint on the Data instance and to use `(%)` rather than `(:%)` in the `gfoldl` and `gunfold` code. This restores the invariant and matches the behavior of "virtual constructors" we've used to patch up such problems elsewhere. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10011> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #5376: Quotation in System.Process.system for Windows
by GHC 20 Mar '15

20 Mar '15

#5376: Quotation in System.Process.system for Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: snoyberg Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.0.4 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => Windows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5376#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs
by GHC 20 Mar '15

20 Mar '15

#2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: task | thoughtpolice Priority: low | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => task Comment: From Phab:D694: "If there still are broken binutils around, then maybe we should simply leave the current code (which works) in for another 10 years." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10165: Win32 broken with GHC 7.10 RC3
by GHC 20 Mar '15

20 Mar '15

#10165: Win32 broken with GHC 7.10 RC3 ---------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem: {{{ C:\Neil>ghci GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help Prelude> import System.Win32 Prelude System.Win32> wRITE_DAC <interactive>: C:\ghc\ghc-7.10.0.20150316\lib\Win32_6dnIMpnCmqmCdDB983aKnr\HSWin 32-2.3.1.0-6dnIMpnCmqmCdDB983aKnr.o: unknown symbol `_SetWindowLongPtrW' ghc.exe: unable to load package `Win32-2.3.1.0' }}} This seems very serious, and breaks all packages that indirectly depend on the Win32 module (which on Windows is most of them). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows.
by GHC 20 Mar '15

20 Mar '15

#7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Replying to [comment:12 gintas]: > No, I am sure I was using hsc2hs from Haskell Platform 2014.2.0.0. I just retested, it works perfectly fine. edwinhere: please reopen again if you're still having problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7191#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9572: nofib target for just building should be part of validate
by GHC 20 Mar '15

20 Mar '15

#9572: nofib target for just building should be part of validate -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.2 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- nofib is never run during validates, which makes it easy to bitrot (c.f. AMP changes). It would be better if: 1. We had a build target for just building nofib tests, not running them, (maybe optionally with optimizations turned off, or just `-fno-code`) and 2. This build target was executed during validates This should strike a balance between wanting to avoid having to spend a lot of time running the benchmarks on validate, while still exercising the nofib tests to some degree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9572> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9609: GHCi gives overly specific error message for unknown constructor
by GHC 20 Mar '15

20 Mar '15

#9609: GHCi gives overly specific error message for unknown constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- What happens: {{{ Prelude> :i Fish Top level: Not in scope: data constructor ‘Fish’ }}} This is potentially confusing because `:i` can be used for type constructors and classes, as well as data constructors. What I think should happen: {{{ Prelude> :i Fish Top level: Not in scope: constructor or class ‘Fish’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9956: Command line flag deprecated warning could be annoying for -Werror users
by GHC 20 Mar '15

20 Mar '15

#9956: Command line flag deprecated warning could be annoying for -Werror users -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In 7.10 we deprecated the poorly named `-package-name` for `-this-package- key`. However, I was working with GHC's validate script and I noticed that this behavior actually might be pretty annoying, because it causes GHC to fail on `-Werror`, and there doesn't seem to be any way of turning off this behavior. So maybe we should add a -fno-warn flag which controls flag warnings. But old GHCs wouldn't accept that flag, so it doesn't make it any more convenient for people to keep their old build scripts running while squelching the warning. Or we could drop the deprecation warning for now and start bleating about it next release. Setting priority high because whatever we decide to do, we need to decide it before 7.10 release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2