- ghc-tickets - Haskell.org

[GHC] Batch modify: #7651, #4471, #7478, #8095, #8736, #8832, #9198, #9968, #10067, #9821
by GHC 10 Mar '15

10 Mar '15

Batch modification to #7651, #4471, #7478, #8095, #8736, #8832, #9198, #9968, #10067, #9821 by thoughtpolice: milestone to 7.12.1 Comment: Moving to the 7.12.1 milestone, as these tickets won't be fixed in time for the 7.10.1 release (unless you, the reader, help write a patch :) -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=7651%2C4471%2C7478%2C8095%2C8736%2…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10128: Data.List.transpose needs more docs
by GHC 10 Mar '15

10 Mar '15

#10128: Data.List.transpose needs more docs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.4 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- as mentioned by Doug McIlroy on haskell-prime. My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs: > The transpose function transposes the rows and columns of its argument. For example, > > {{{ > transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]] > }}} > > If some of the rows are shorter than the following rows, their elements are skipped: > > {{{ > transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]] > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10058: Panic: Loading temp shared object failed
by GHC 10 Mar '15

10 Mar '15

#10058: Panic: Loading temp shared object failed -----------------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I ran into a panic when updating `singletons` for 7.10. I'm clueless as to what's going on here, so sorry for not minimizing the test case. A little testing has me convinced it's Template Haskell in some way. To reproduce: {{{ > git clone http://github.com/goldfirere/singletons.git > cd singletons > git checkout ghc-loading-panic-test-case > cabal update > cabal install --only-dependencies > cabal configure > cabal build > cat dist/build/autogen/cabal_macros.h # copy the value for CURRENT_PACKAGE_KEY from the end of cabal_macros.h > cd tests/compile-and-dump > ghc -c -this-package-key <package key from cabal_macros.h> -i../../dist/build -XTemplateHaskell Singletons/Maybe.hs }}} You will see something like {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150123 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib, 5): Symbol not found: _mtlzuJNaGzzEkFfL43R3LZZNRlPRm_ControlziMonadziReaderziClass_DZCMonadReader_con_info Referenced from: /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib Expected in: flat namespace in /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've observed this on a Mac, but Travis has the same problem, so it's not strictly Mac-specific. You can see representative Travis output [https ://travis-ci.org/goldfirere/singletons/jobs/49103793 here]. Why am I doing such a crazy thing? It's part of the `singletons` test suite, where it's important to test the output of a run of ghc with `-ddump-splices`. Getting the test cases to compile against the built-but- not-yet-installed `singletons` object files should work with `-this- package-key`. I'm sure there's a better way to structure a testsuite, but this general technique works (with `-package-name` instead of `-this- package-key`) with 7.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #9524: GHC uses wrong linker when cross compiling
by GHC 10 Mar '15

10 Mar '15

#9524: GHC uses wrong linker when cross compiling -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Greetings, I tried to compile a cross compiler for x86_64-w64-mingw32. Most of GHC compiles fine. However, after a while there's an error that ld can't find a reference to "GetModuleFileNameW". I tried compiling a dummy C program with that symbol and it compiles fine. My guess is that GHC is using the wrong linker during cross-compiling, whereas GCC uses the right one. But I may be totally wrong, so please don't rely on that judgement. The log of the make run is attached. Regards Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10113: Re-export (<$>) from Prelude
by GHC 10 Mar '15

10 Mar '15

#10113: Re-export (<$>) from Prelude -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: highest | Version: 7.10.1-rc2 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: AMP | Blocked By: Architecture: | Related Tickets: #4834 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: Phab:D680 | -------------------------------------+------------------------------------- See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10113> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 09 Mar '15

09 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by simonpj): Well, bugs (and this was a bug) are like that! It's not so hard, and it is truthful, to add `ConstrainedClassMethods` to those libraries. But if the CLC advises, we can also make `FlexibleContexts` imply it. Remember this is not in 7.10 so libraries have time to adapt. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 09 Mar '15

09 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by ekmett): It has been around for a long time, but I know at least a few of us were rather startled when we started getting error messages about it and every occurrence I've found so far is a module where I have FlexibleContexts already enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 09 Mar '15

09 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by simonpj): Herbert's point is a good one. But it would not be impossible to make `FlexibleContext` also imply `ConstrainedClassMethods`, if that was vastly better. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10144: Variant of runGhc which accepts prelude for setting up DynFlags
by GHC 09 Mar '15

09 Mar '15

#10144: Variant of runGhc which accepts prelude for setting up DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- One of the long-standing awkwardness of using the GHC API is the need to call `setSessionDynFlags` *again* after you finish setting up the DynFlags with all the parameters you care about. Furthermore, you must run `getSessionDynFlags` AGAIN in order to get the "most up-to-date" version of `DynFlags`, because the package initialization process twiddles with values in `DynFlags`. That's terrible. What we would like to do is set an invariant that there will be NO non- user changes to DynFlags. That means `pkgDatabase`, `pkgState` and `thisPackage`, which are twiddled by `initPackages`, really *ought not* to live in `DynFlags`. This would also fix a pile of nattering about with copying these values between the interactive DynFlags and normal DynFlags. However, there is a problem with trying to do this: most of the functions in `Packages` assume only a `DynFlags` is available. And you can basically assume that you'll have a `DynFlags` everywhere; not so much for `HscEnv`. So actually fixing this would require a lot of code heaving around that I'm not too interested in at the moment. There is, however, something we can do that will make people's life's better: a new version of `runGhc` which also accepts a function from `GhcMonad m => DynFlags -> m DynFlags` which is responsible for taking the `DynFlags` and configuring it to some suitable state. Whatever is returned, GHC can then make the final modifications (e.g. filling in those fields) and finally setting it as the DynFlags in the HscEnv, and ALSO updating the unsafe global DynFlags. This is not too hard to do. But is it the right thing to do? I'd like to know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

09 Mar '15

#2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: bug | 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: -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, I see the jump table entries are currently padded to 64 bits anyways. So then it should be slightly better to use a 64-bit relocation instead, but maybe it would be even better to pack the entries into 32 bits instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0