March 2015 - ghc-tickets

[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

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: -------------------------------------+------------------------------------- Changes (by nomeata): * priority: normal => low Comment: As austin writes in Phab:D694, we are not going to able to change that in the near future anyways. Lowering severity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs (was: Remove Hack in compiler/nativeGen/MachCodeGen.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: normal | 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): I would not be surprised if it was better (equal or faster performance and smaller object file size) to use 32-bit offsets anyways, has anyone done a performance test? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4372: Extending quasiquotation support
by GHC 09 Mar '15

09 Mar '15

#4372: Extending quasiquotation support -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): songzh: `'[' quoterExp '|' strings '|]'` is not really possible since it looks too much like any list comprehension. If you wrote `[ x * y | x <- [1,2,3], y <- [4,5] ]` is that a list comprehension or the beginning of a quasiquote, that might terminate arbitrarily far away? With quasiquotes as they stand now you cannot write a list comprehension like `[x|x<-[1,2,3]]`; you must include a non-identifier character before the `|`. That's a mild imposition, but it is already something, and I don't see how the syntax can be pushed much farther. As for the ticket in general: Quasiquotes offer two conveniences over TH splices: overloading the same name to refer to expression, pattern, etc. splice generators; and raw string literals (terminated by `|]`). The overloading can be nice, but is never essential (the resolution is purely syntactic anyway) and often you only need the expression quoter. The raw string literal syntax is quite useful, but it's a problem that only needs to be solved once. Specifically, once you have a quasiquoter `q` that produces string literals, you can rewrite any {{{ [foo|bar|] }}} as {{{ $(foo [q|bar|]) -- this 'foo' is the old 'quoteExp foo'. -- at worst, you could call it 'fooE' or something. }}} which is already not that much longer; and any syntax for parameterized quasiquoters would have to be longer than `[foo arg|bar|]`, so there's very little room left for improvement over what we can build with the pieces we have today. So basically I agree with Gershom: the workaround he suggested is always possible, it's pretty lightweight, and it's hard to see how a new syntax for this would really be worth it, when it can't gain much (and has the opportunity cost of not being able to use the syntax for something else). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4372#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0