April 2014 - ghc-tickets

[GHC] #8782: Using GADT's to maintain invariant in GHC libraries
by GHC 22 Jan '16

22 Jan '16

#8782: Using GADT's to maintain invariant in GHC libraries ------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I rewrote `compiler/utils/OrdList.lhs` using a GADT to preserve some invariants stated only in comments — an excellent chance for `ghc` to eat its own proverbial dog food I feel :) The type signatures remain the same so it should be a drop-in replacement but it does use some GHC features that are too recent (closed type families in particular, the `IsList` instance can be removed) making it ineligible for inclusion I believe. hvr on `#ghc` suggested that I submit a patch anyway and that it could be implemented at a later date (they said `ghc` must be able to be compiled by the last two previous major versions), if this is useful then I will translate `Bag.hls` which has the same invariants but more complicated functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8830: internal error: Misaligned section: 18206e5b on Windows
by GHC 21 Jan '16

21 Jan '16

#8830: internal error: Misaligned section: 18206e5b on Windows ----------------------------+------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- Loading package gnutls-0.1.5 ... ghc.exe: internal error: Misaligned section: 18206e5b (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Only occurs when loading the module in as part of a build involving TH. A non-TH-using program using this library links successfully. I have installed a gnutls built for Windows, from http://josefsson.org/gnutls4win/. Different versions have different section offsets, but all the versions I've tried fail like this. I've also gotten the same error linking gnuidn, instead of gnutls, with gnuidn from ftp://ftp.gnu.org/gnu/libidn/libidn-1.28-win32.zip This makes me think this may be a general ghci on windows bug, rather than a misbuilt library. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8850: (Compositional) function mkWeakChan
by GHC 21 Jan '16

21 Jan '16

#8850: (Compositional) function mkWeakChan ------------------------------------+------------------------------------- Reporter: bholst | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7285 | ------------------------------------+------------------------------------- Following the existing functions mkWeakIORef and mkWeakMVar, I'd like to have a function mkWeakChan with the following type signature, similar to that of mkWeakMVar requested by ticket #7285: {{{ mkWeakChan :: Chan a -> v -> Maybe (IO ()) -> IO (Weak v) }}} The implementation of '''Chan''' is private, so it is not easily possible to implement it yourself. The implementation of both functions may look like the following: {{{ mkWeakMVar :: MVar a -> v -> Maybe (IO ()) -> IO (Weak v) mkWeakMVar (MVar m#) v (Just f) = IO $ \s -> case mkWeak# m# v f s of (# s1, w #) -> (# s1, Weak w #) mkWeakMVar (MVar m#) v Nothing = IO $ \s -> case mkWeakNoFinalizer# m# v s of { (# s1, w #) -> (# s1, Weak w #) } mkWeakChan :: Chan a -> v -> Maybe (IO ()) -> IO (Weak v) mkWeakChan c@(Chan readVar writeVar) v f = do _ <- mkWeakMVar readVar writeVar Nothing mkWeakMVar writeVar v f }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8850> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8859: import conditionalization in System.Posix.Files.Common is wrong
by GHC 21 Jan '16

21 Jan '16

#8859: import conditionalization in System.Posix.Files.Common is wrong ------------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.1-rc2 Keywords: | Operating System: Other Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- `System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid "unused import" compiler warnings: {{{ #if defined(HAVE_STRUCT_STAT_ST_CTIM) || \ defined(HAVE_STRUCT_STAT_ST_MTIM) || \ defined(HAVE_STRUCT_STAT_ST_ATIM) || \ defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \ defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \ defined(HAVE_STRUCT_STAT_ST_CTIMESPEC) import Data.Int import Data.Ratio #endif }}} but those modules are actually used in functions like {{{ accessTimeHiRes (FileStatus stat) = unsafePerformIO $ withForeignPtr stat $ \stat_ptr -> do sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime #ifdef HAVE_STRUCT_STAT_ST_ATIM nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIMESPEC nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIMENSEC nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIME_N nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_UATIME usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int) let frac = toInteger usec % 10^(6::Int) #else let frac = 0 #endif return $ fromRational $ toRational sec + frac }}} so there should be additional tests for `defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)`, `defined(HAVE_STRUCT_STAT_ST_ATIME_N)`, ... (15 total). Or, maybe there's a better alternative, since this is very long-winded and fragile... This breaks the build on Android, which has `st_atimensec`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8904: haddock displays GHC.Types.Coercible as a datatype
by GHC 21 Jan '16

21 Jan '16

#8904: haddock displays GHC.Types.Coercible as a datatype ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- ...and not as a class. Appeared after #8894 was fixed. It is correct in Data.Coerce and GHC.Exts, so this is a minor issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX
by GHC 21 Jan '16

21 Jan '16

#8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX ----------------------------------+---------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Target is `x86_64-pc-linux`. I'm using the toolchain from http://crossgcc .rts-software.org/doku.php, and configured `--with-target=x86_64-pc- linux`. {{{ ===--- building phase 0 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=1 phase_1_builds utils/unlit/ghc.mk:18: utils/unlit/dist/build/.depend.c_asm: No such file or directory utils/hp2ps/ghc.mk:24: utils/hp2ps/dist/build/.depend.c_asm: No such file or directory includes/ghc.mk:146: includes/dist-derivedconstants/build/.depend.c_asm: No such file or directory includes/ghc.mk:184: includes/dist-ghcconstants/build/.depend.c_asm: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.haskell: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.c_asm: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.haskell: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist- boot/build/.depend-v.haskell: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.haskell: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist- boot/build/.depend-v.haskell: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/build/.depend-v.c_asm: No such file or directory compiler/ghc.mk:450: compiler/stage1/build/.depend-v.haskell: No such file or directory HC [stage 0] includes/dist-ghcconstants/build/mkDerivedConstants.o In file included from rts/Capability.h:25, from includes/mkDerivedConstants.c:27:0: rts/Task.h:238:0: error: thread-local storage not supported for this target make[1]: *** [includes/dist-ghcconstants/build/mkDerivedConstants.o] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse..
by GHC 21 Jan '16

21 Jan '16

#8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. ------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- The ReadP monad maintains all possible parses of its input, rather than being left-biased as most parsers are. However this is not always quite the Right Thing. I maintain the Data.Decimal library. The Read instance for Data.Decimal up to 0.3.1 had the following behaviour: reads "34.567e8 foo" :: [(Decimal, String)] = [(34.0,".567e8 foo"),(34.567,"e8 foo"),(3.4567e9," foo")] Clearly only the last parse in the list is the Right Thing, and any parser which returns "34.0" when given "34.567" is doing it wrong. The problem came from the implementation of "optional". In numbers only the integer part is mandatory, with the fractional and exponent parts being optional. So I wrote my parser with the fractional part parsed like this: fractPart <- optional "" $ do _ <- char '.' munch1 isDigit The problem is that "optional" uses the symmetric choice operator (+++). I wrote this to work around the problem: myOpt d p = p <++ return d This uses the left-biased choice, so as soon as the parser sees the "." it commits to the fractional part. However this still isn't the Right Thing. reads "34." :: [(Double, String)] = [(34.0, ".")] but the parser above will fail to read it. Furthermore there are a number of combinators built on "+++" in ReadP, and it seems wrong to have left- biased variants of all of them. So what seems to be needed is some kind of "cut" operator, analogous to the Prolog "!" cut, which says that if you have got this far then you should commit to this parse and forget all the others. But it would have to be delimited because I only want that cut to apply to my Decimal type: if someone calls my Decimal parser then I don't want their parser to commit to an entire parse just because I have. So I think the feature I'm looking for is a delimited back-track akin to "prompt" in delimited continuations. But my monad-fu isn't good enough to design it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind"
by GHC 21 Jan '16

21 Jan '16

#8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" ----------------------------------+--------------------------------- Reporter: tbelaire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I was tying to get hdevtools to work, and cloned it and pulled in a bunch of the open pull requests. You can see the state it's in at github.com/tbelaire/hdevtools. {{{ git clone git@github.com:tbelaire/hdevtools cd hdevtools cabal sandbox init cabal install cd .. }}} I could not reproduce the problem on a small test file, so I'm afraid I'll have to demonstrate it on my vinyl-json package. {{{ git clone git@github.com:tbelaire/vinyl-json cd vinyl-json/ cabal sandbox init cabal install hdevtools type src/Data/Vinyl/JSON.hs 42 15 panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-apple-darwin): Evaluated the place holder for a PostTcKind Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I also get hpc has closed due to a problem a lot when compiling things, but I think that's unrelated. The dynamic lib seems to be gone. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8947: Depending on hint/ghc API fixes the binary version I can use
by GHC 21 Jan '16

21 Jan '16

#8947: Depending on hint/ghc API fixes the binary version I can use ----------------------------+---------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- When I `build-depend` on hint-0.4.0.0 with GHC 7.6.3, I get {{{ % cabal configure Resolving dependencies... cabal: Could not resolve dependencies: trying: pointcloudviewer-0.1.0 (user goal) trying: hint-0.4.0.0/installed-cf3... (dependency of pointcloudviewer-0.1.0) trying: ghc-7.6.3/installed-494... (dependency of hint-0.4.0.0/installed-cf3...) trying: bin-package-db-0.0.0.0/installed-608... (dependency of ghc-7.6.3/installed-494...) trying: GLUtil-0.7.4/installed-223... (dependency of pointcloudviewer-0.1.0) next goal: linear (dependency of GLUtil-0.7.4/installed-223...) rejecting: linear-1.6/installed-300... (conflict: bin-package-db => binary==0.5.1.1/installed-72e..., linear => binary==0.7.1.0/installed-a33...) }}} This fails because `linear` uses a `binary > 0.5.1.1`, but through my use of `hint` which depends on `ghc` (`hint` does not directly depend on `binary`), I pull in a constraint `binary == 0.5.1.1`. I believe this is bad, because depending on the GHC API in any way fixes the binary version I can use, which immediately makes a range of newer libraries unavailable to my program. Probably GHC should somehow hide the fact that binary is used inside, and let the rest of my program use whatever binary it likes. ---- I am aware that this might not be immediately easy, since the GHC API might expose some `binary` types to my program that I could try use with my newer binary version, which of course would be illegal. Maybe it is possible to implement such a check into actual typechecking, and let it pass if I don't actually use types from the old version with functions from the new library. I actually believe I have seen compiler errors in the past where two identical types where not unified because one was from a different version, so maybe infrastructure for this is already in place? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8992: Instructions for using gdb with GHC on Windows
by GHC 21 Jan '16

21 Jan '16

#8992: Instructions for using gdb with GHC on Windows ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- gdb remains a useful tool for debugging executables on Windows, but getting it setup can be tricky, since modern gdb requires Python, which means you will end up installing MSYS Python alongside native Python. Unfortunately, MSYS Python doesn't work with the test suite, so one is in the delicate situation where you want your path to have MSYS Python if you're running gdb, but Windows Python if you're running the test suite. While one can work around this with modest annoyance (the easiest thing I've found is to just uninstall gdb/python when I'm not using it), it would be better if we removed this friction in some way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3