September 2013 - ghc-tickets

[GHC] #8223: System.Posix.User fails to build on systems without get{gr, pw}nam_r
by GHC 09 Oct '13

09 Oct '13

#8223: System.Posix.User fails to build on systems without get{gr,pw}nam_r ----------------------------------+---------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Keywords: | Operating System: Other Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I'm trying to build GHC for Android (using https://github.com/neurocyte /ghc-android) and according to `include/HsUnixConfig.h` Android doesn't have any of the `_r` functions in the `get{gr,pw}*` family. In `System/Posix/User.hsc` the imports of `Control.Monad` and `System.IO.Error` are conditional on `defined(HAVE_GETGRNAM_R) || defined(HAVE_GETPWNAM_R)`, but the use site of those modules (`doubleAllocWhileERANGE`) was moved outside of any `#if`s by http://git.haskell.org/?p=packages/unix.git;a=commit;h=ef683c6ba703. I would suggest just removing the conditionals around the import of those two modules, since `doubleAllocWhileERANGE` is by now used by four other functions. Otherwise, need to bracket the definition of `doubleAllocWhileERANGE` with the same conditional as the one around those imports, and should update the conditionals to reflect all four cases in which `doubleAllocWhileERANGE` is used. (BTW, does Android count as "Operating System: Linux"? It is based on the Linux kernel, but with a rather peculiar user-space.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8367: putStrLn and related printing functions don't output to MinTTY properly under Windows
by GHC 09 Oct '13

09 Oct '13

#8367: putStrLn and related printing functions don't output to MinTTY properly under Windows ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- One place where this glitch can be seen in `cabal update` by it *delaying* the term output until the update is finished and the program terminates. I've noticed it in several of my personal larger projects too. I think what's going on is that nothing is printed to the terminal until the program terminates. It seems to be intermittent to some degree, and varying the size and contents of the program can trigger it. Because of it's indeterminacy I can't actually provide a small test case, however, I can provide a program which currently does produce the issue. https://github.com/kvanberendonck/burrito/blob/ccd8d1fb2bb09251571cf2626314… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8047: Implement line-number %-substitution for prompt-string
by GHC 07 Oct '13

07 Oct '13

#8047: Implement line-number %-substitution for prompt-string ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, GHCi supports the following `%`-interpolations: > `:set prompt prompt` > > Sets the string to be used as the prompt in GHCi. Inside prompt, the sequence %s is replaced by the names of the modules currently in scope, and %% is replaced by %. If prompt starts with " then it is parsed as a Haskell String; otherwise it is treated as a literal string. The attached patch implements the `%l` variable, which gets replaced by the current line number of the shown prompt. The motivation being, that compiler messages refer to interactively entered bindings by the line number when they were defined, which are a bit hard to keep track of, e.g.: {{{ λ> :set prompt "\955:%l> " λ:3> let x = () x :: () λ:4> let x = ((),()) x :: ((), ()) λ:5> print xx <interactive>:5:7: Not in scope: ‛xx’ Perhaps you meant ‛x’ (line 4) λ:6> :info x x :: ((), ()) -- Defined at <interactive>:4:5 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci
by GHC 07 Oct '13

07 Oct '13

#8383: "tagToEnum# (0# ==# 1#) :: Bool" causes CASEFAIL in ghci ----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- {{{ rwbarton@adjunction:~/dist/ghc/libraries/base/tests$ echo main | ~/dist/ghc/inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --interactive -v0 -ignore-dot-ghci tup001d.hs <interactive>: internal error: interpretBCO: hit a CASEFAIL (GHC version 7.7.20130928 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} This causes libraries/base test `tup001` to fail in the same way with WAY=ghci, because the derived instance of Eq for enumeration-like types of more than 10 constructors does something like `x == y = tagToEnum# (getTag x ==# getTag y)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8297: Allow implicit parameters to take a default value
by GHC 07 Oct '13

07 Oct '13

#8297: Allow implicit parameters to take a default value ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- -XImplicitParams is not that useful except as a type hole. I had an idea where they could be adjusted to be really useful. Consider a function `primes` which uses a wheel sieve. {{{ -- primes: takes a size of the wheel to use, returns a lazy list of primes primes :: Int -> [Int] }}} Your average Joe may not be concerned about the technical details of this function. Why should he have to bother giving a wheel size? The function documentation might say `6` is a good value, but what if some research is done in the future and the library maintainer changes it, later deciding `7` is better? Joe wants to trust the library maintainer, but doesn't want to be burdened by maintaining this arbitrary constant in his code, nor does he like having to pass another parameter to primes. The type of `primes` could be implemented using an implicit parameter like this: {{{ primes -- returns an infinite list of primes primes :: (?wheelSize :: Int) -> [Int] }}} Joe still has to provide a wheelSize however, and now it's even more verbose than before. Wouldn't it be nice if the person who wrote the function could define a default value for `wheelSize`? Joe could use `primes` by itself in his code, whereas Bob, who runs his code on a very powerful server, could tune the performance of his sieve manually by explicitly using `primes where wheelSize = 100`. My suggestion is to develop a syntax which allows functions to define ''default'' values for their implicit parameters. I'm sure the community would have some fun coming up with creative uses for this in their libraries! As an extreme situation, consider the below example; {{{ -- takes a foo, bar, alpha, beta, gamma and epsilon for performance tuning. ouch. aVeryComplexSieveEx :: Int -> Int -> Int -> Int -> Int ... -> r -- f $ aVeryComplexSieveEx 1 2 3 4 ... aVeryComplexSieveEx :: SomeCompulsaryRecordConstructor -> Int -> r -- f $ aVeryComplexSieveEx (SomeCompulsaryRecordConstructor { ... }) 3 }}} vs {{{ aVeryComplexSieveEx :: (?foo :: Int, ?bar :: Int, ?alpha :: Int, ?beta :: Int, ?gamma :: Int) -> Int -> r -- f $ let ?alpha = 1337 in aVeryComplexSieveEx 3 }}} As you can see it would be beneficial for libraries to expose *optional* ways for users to tune internal values in this manner, without having to pass record constructors with many options or make new functions with tiresome numbers of parameters. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8173: GHC uses nub
by GHC 05 Oct '13

05 Oct '13

#8173: GHC uses nub -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Moderate (less | performance bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- nub is O(n²). I bet all usages have Ord instances. https://github.com/nh2/haskell-ordnub -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 18

[GHC] #8260: Parallel build behaves erratic under Windows
by GHC 05 Oct '13

05 Oct '13

#8260: Parallel build behaves erratic under Windows ----------------------------------+---------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Under Windows, `make -j4` will freeze randomly all through the build system (every ~ 1-2 minutes). The only way to get it to resume it is to kill the make process and restart it. It sometimes even freezes on things like `rm` or `happy`. This makes building GHC take an unbearably long time. Tested on latest MinGW. {{{ GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i686-pc-msys }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8259: HEAD won't build on Windows
by GHC 05 Oct '13

05 Oct '13

#8259: HEAD won't build on Windows -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Related output: {{{ [68 of 68] Compiling Main ( utils\ghc-cabal\Main.hs, bootstrapping\Main.o ) utils\ghc-cabal\Main.hs:229:51: Not in scope: `componentsConfigs' utils\ghc-cabal\Main.hs:231:32: `componentsConfigs' is not a (visible) constructor field name utils\ghc-cabal\Main.hs:290:37: Not in scope: `componentsConfigs' utils\ghc-cabal\Main.hs:291:45: Not in scope: data constructor `LibComponentLocalBuildInfo' Perhaps you meant `ComponentLocalBuildInfo' (imported from Distribution.Simple.LocalBuildInfo) utils\ghc-cabal\Main.hs:292:37: Not in scope: data constructor `LibraryName' utils\ghc-cabal\Main.hs:292:52: Not in scope: data constructor `LibraryName' utils\ghc-cabal\Main.hs:293:35: Not in scope: data constructor `LibraryName' utils\ghc-cabal\Main.hs:293:52: Not in scope: `componentLibraries' utils\ghc-cabal\Main.hs:294:25: `componentLibraries' is not a (visible) constructor field name utils\ghc-cabal\Main.hs:296:14: `componentsConfigs' is not a (visible) constructor field name utils\ghc-cabal\Main.hs:297:28: Not in scope: `hostPlatform' make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 make: *** [all] Error 2 }}} Fresh HEAD pulled, booted and sync'd <5 minutes ago, built using GHC 7.6.2 (HaskellPlatform) through latest mingw on Windows 8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8133: T7881 fails with hpc
by GHC 04 Oct '13

04 Oct '13

#8133: T7881 fails with hpc ----------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+-------------------------- I noticed that T7881 fails with `hpc` way. I investigated a bit and I noticed that if I compile the program without hpc it emits 3 warnings (which is intended): {{{ [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc- validate2/testsuite/tests/numeric/should_compile] '/5playpen/t-jastol/ghc- validate2/inplace/bin/ghc-stage2' -fforce-recomp -c T7881.hs -O T7881.hs:7:6: Warning: Enumeration is empty T7881.hs:25:6: Warning: Enumeration is empty T7881.hs:31:6: Warning: Enumeration is empty }}} But if I add `-fhpc` on the command line the warnings disappear: {{{ [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc- validate2/testsuite/tests/numeric/should_compile] '/5playpen/t-jastol/ghc- validate2/inplace/bin/ghc-stage2' -fforce-recomp -c T7881.hs -O -fhpc [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc- validate2/testsuite/tests/numeric/should_compile] }}} That's the reason why this test fails (mismatch of stderr). I don't know whether this is expected behaviour of hpc or not. If the former, then test configuration should be fixed, if the latter then hpc itself should be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8368: Panic in rejigConRes
by GHC 03 Oct '13

03 Oct '13

#8368: Panic in rejigConRes ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I compile the following erroneous code {{{ {-# LANGUAGE DataKinds, TypeFamilies, GADTs #-} import GHC.TypeLits data Foo = Bar data instance Sing (n :: Foo) where SBar :: Sing Foo }}} I get {{{ *** Exception: compiler/typecheck/TcTyClsDecls.lhs:1266:5-62: Irrefutable pattern failed for pattern Data.Maybe.Just subst }}} I think this is my fault. I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7