November 2015 - ghc-tickets

[GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_
by GHC 18 Nov '15

18 Nov '15

#10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | 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: | -------------------------------------+------------------------------------- These need only an Applicative constaint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11104: Typo in Debug.Trace documentation
by GHC 17 Nov '15

17 Nov '15

#11104: Typo in Debug.Trace documentation -------------------------------------+------------------------------------- Reporter: asthasr | Owner: asthasr Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation for `traceShowM` refers to it as `traceMShow`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows
by GHC 17 Nov '15

17 Nov '15

#3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+---------------------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T3242 Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Phab:D1455 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows
by GHC 17 Nov '15

17 Nov '15

#3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+---------------------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T3242 Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Phab:D1455 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"acce37f38bc3867f86cf717694915746bb2f278e/ghc" acce37f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="acce37f38bc3867f86cf717694915746bb2f278e" Fix archive loading on Windows by the runtime loader The runtime loader is unable to find archive files `.a` shipping with the inplace `GCC`. It seems the issue is caused by `findArchive` being unable to find any archives that are shipped using the in-place `GCC`. - It works on Linux because `findArchive` would search the standard Linux include path. - It works during compilation because `GCC` can find it's own libraries (we explicitly tell it where to look for libraries using the `gcc` wrapper around `realgcc`) So fixing the issue means using `searchForLibUsingGcc` in `findArchive` as well, which will then find the correct file. The reason for the error as it is, is because if we can't locate the library using any of the methods we have, we assume it is a system dll, or something on the system search path. e.g. if trying to load `kernel32.dll`. There is a slight issue in that the `GHCi` code (incorrectly) favors `static archives` over `dynamic` ones ``` findDll `orElse` findArchive `orElse` tryGcc `orElse` tryGccPrefixed `orElse` assumeDll ``` This has the unwanted effect of when `kernel32` is specified as a lib, it will try to load `kernel32.a` instead of `kernel32.dll`. To solve this I have added another search function that is able to search the Windows search paths using `SearchPath` in order to find if it is a dll on the system search path. The new search order is: ``` findDll `orElse` findSysDll `orElse` tryGcc `orElse` findArchive `orElse` assumeDll ``` (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at top level) Test Plan: ./validate added new windows tests T3242 Reviewers: thomie, erikd, hvr, austin, bgamari Reviewed By: thomie, erikd, bgamari Differential Revision: https://phabricator.haskell.org/D1455 GHC Trac Issues: #3242 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11101: Expand Template Haskell type splices before quantification
by GHC 17 Nov '15

17 Nov '15

#11101: Expand Template Haskell type splices before quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ f :: Int -> $(foo) f = ... }}} This is a Template Haskell type splice. What if `$(foo)` expands to `a -> a`. Then it should all behave as if you'd written {{{ f :: Int -> a -> a f = ... }}} But it doesn't, because we collect the variables over which we will implicitly quantify ''before expanding splices''. This is made yet more tricky when we add type wildcards to the mix. And really there is no good reason for this trouble. We should simply expand the splice, and ''then'' decide what to quantify over. A little bit of refactoring in `RnTypes`. This ticket is just to record that I intend to do this shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4243: Make a proper options parser for the RTS
by GHC 16 Nov '15

16 Nov '15

#4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"69822f0c5b67161b4d7558081bc94f6f3a7c5dbb/ghc" 69822f0c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69822f0c5b67161b4d7558081bc94f6f3a7c5dbb" RtsFlags: Refactor some of the deeper switches This was previously nearly impossible to read; now it's merely difficult. Ideally we would do a more thorough refactoring of the RTS command line parser (#4243) but this is more effort than I have time for at the moment. Test Plan: Try using affected RTS flags Reviewers: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1476 GHC Trac Issues: #4243 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4243#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10276: ApiAnnotations : ITopenExpQuote needs SourceText
by GHC 16 Nov '15

16 Nov '15

#10276: ApiAnnotations : ITopenExpQuote needs SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the lexer, `ITopenExpQuote` can be recognised for '[e|' or '[|'. The token definition needs to capture the original `SourceText`, and pass it through to `ExpBr`, which also needs a `SrcText` field. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens
by GHC 16 Nov '15

16 Nov '15

#11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment there is no way to tell if a given token used its unicode variant or its normal one, except to look at the length of the token. This fails for the unicode '*'. Expose the original source text for unicode variants so that API Annotations can capture them specifically. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #5063: unix package has untracked dependency on libbsd
by GHC 16 Nov '15

16 Nov '15

#5063: unix package has untracked dependency on libbsd -------------------------------------+------------------------------------- Reporter: duncan | Owner: trommler Type: bug | Status: upstream Priority: low | Milestone: 8.0.1 Component: Core Libraries | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett (added) * status: new => upstream -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5063#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3242: GHCi linker does not correctly locate static libraries under Windows
by GHC 16 Nov '15

16 Nov '15

#3242: GHCi linker does not correctly locate static libraries under Windows ---------------------------------+---------------------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T3242 Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Phab:D1455 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by lukexi): * milestone: 8.0.1 => 7.10.3 Comment: We should get this into 7.10.3 if possible, as it's another showstopper for linking certain C/C++ libraries on Windows in the presence of Template Haskell (see #10726). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0